Client Area von Formular disablen

[s.h.a.r.k]

Ich suche gerade nach eine Möglichkeit, die Client Area einer Form zu deaktivieren -- schaut das Bild im Anhang an, dann wisst ihr, was mit Client Area gemeint ist. Ich könnte auch alle Komponenten auf ein Panel platzieren und PanelXYZ.Enabled := False; setzen, was aber für mich nicht brauchbar ist. Ich habe keinerlei Informationen über das Formular selbst, daher soll die Lösung eben so allgemein wie nur möglich sein.

Ebenso soll das Fenster selbst immer noch bewegbar bleiben, ebenso in der Größe änderbar! Bisher habe ich leider keinerlei Message oder sonst eine Idee gefunden, die nur die Client Area disabled.

Quelle des Bildes.

[generic]

Die Antwort ist hier:
http://delphihaven.wordpress.com/201...stom-titlebar/

MSDN:
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

DWM gibts erst ab Vista!
Für XP musst du das anders lösen.

[s.h.a.r.k]

Ich glaube nicht, dass da die Lösung zu finden sind, auf die ich anspiele. Ich habe nich vor in den Non-Client-Bereich etwas zu zeichnen. Ich will nur den Client-Bereich "sperren" -- als Beispiel dazu habe ich ja das mit dem Panel erwähnt. Befinden sich Komponenten auf dem Panel und ich setze die Enabled-Eigenschaft des Panels auf False, so kann ich die Komponenten darauf nicht mehr nutzen. Das gleiche will ich für das Formular haben, allerdings soll es noch möglich sein, das Formular in der Position und größe zu ändern.

[Assarbad]

Moin,

mir ist nichts bekannt was genau das erreicht, da der Clientbereich bekanntlich kein eigenes Fenster ist.

Ein TPanel wäre in der Tat ein Lösungsansatz.

Aber wenn ich mir die Frage so anschaue, geht es doch darum alle Bedienelemente zu deaktivieren usw., oder? Warum dann nicht mit EnumWindows über alle Kindfenster gehen und die eines nach dem anderen deaktivieren. Wenn dann bspw. noch das Problem wäre, daß einige Kindfenster bereits deaktiviert sind und du deshalb deren aktuellen Status speichern mußt, kannst du das entweder unkompliziert über eine Liste in deinem Programm oder über Fenstereigenschaften (SetProp und GetProp aus user32.dll) lösen.

[s.h.a.r.k]

Das mit dem deaktivieren habe ich mir auch schon angeschaut, finde aber nicht, dass es eine schöne Lösung ist, eben aus besagten Gründen bzgl. evtl. schon deaktivieren Elementen. Wobei ich diese EnumWindows-Methode noch nicht kannte, die könnte die Sache einfacher machen. Ich habe dabei aber leider die Befürchtung, dass dieses Verhalten unter Umständen irgendwelche Seiteneffekte hervorrufen kann, z.B. wenn ich einen wichtigen Timer deaktivere. Für meinen speziellen Fall würde das schon klappen, aber unter Umständen nicht allgemeingültig.

Und TPanel will ich eigentlich nicht nutzen, da ein paar Programmierer evtl. folgendes machen: TForm(Button1.Parent).Caption := 'Test'; . Setze ich dynamisch ein Panel ein, so funktioniert dieser Quellcode evtl. nicht mehr. Ich weiß zwar nicht, wie oft sowas auftauchen kann, aber bei sowas bin ich dann doch gerne vorsichtig.

[SirThornberry]

Und wenn du einfach auf wm_nchittest reagierst und da hterror zurück gibst oder im schlimmsten Fall httransparent

[Assarbad]

Zitat von s.h.a.r.k:

z.B. wenn ich einen wichtigen Timer deaktivere.

Ein Timer ist kein Fenster!

Es geht also um eine Komponente?

[s.h.a.r.k]

Zitat von SirThornberry:

Und wenn du einfach auf wm_nchittest reagierst und da hterror zurück gibst oder im schlimmsten Fall httransparent

Das verstehe ich noch nicht ganz. Muss mir erst die Message WM_NCHITTEST anschauen

Zitat von Assarbad:

Zitat von s.h.a.r.k:

z.B. wenn ich einen wichtigen Timer deaktivere.

Ein Timer ist kein Fenster!

Es geht also um eine Komponente?

Achso... Ich meinte, dass das die einzelnen Komponenten, die ein Handle haben durchgeht.

[Assarbad]

Zitat von s.h.a.r.k:

Achso... Ich meinte, dass das die einzelnen Komponenten, die ein Handle haben durchgeht.

Die Frage ob es um eine Komponente geht war unabhängig von der Bemerkung, daß ein Timer kein Fenster ist.

Fenster haben logischerweise ein Handle und du kannst sie mit o.g. Funktion listen. Alle üblichen Komponenten sind damit abgedeckt, aber sowas wie ein TLabel wäre nicht abgedeckt da es "nur" auf sein Elternfenster gezeichnet wird. Es ist kein echtes Fenster im Windows-Sinne.

[s.h.a.r.k]

Ich sollte wohl noch den Sinn des ganzen erklären, da eine einfache Lösung wohl direkt nicht zu existieren scheint. Und zwar programmiere ich ein Overlay-Fenster, welches sich (semitransparent) über das "Parent"-Fenster legt. Beispielanwendung dafür wäre z.B. ein Ladescreen, oder von mir aus auch ein Login-Screen. Der Borderstyle des Overlays ist bsNone und das Overlay-Formular ist genau so groß, wie der Client-Bereich der darunter liegenden Form. Beide Formulare sollen fokusierbar sein, sodass auf dem Overlay gearbeitet werden und das Hauptformular verschoben bzw. in der Größe verändert werden kann -- das Overlay-Formular setzt automatisch immer die exakte Größe und Position, sodass es immer den Client-Bereich überdeckt.

Nun ist es aber eben so, dass wenn ich dann auf das "Parent"-Window klicke ich den Fokus auf die Controls dort setze, d.h. ein User kann mit Tab etc. den Fokus ändern und evtl. ungewünschte Aktionen ausführen. Im Falle eines Ladescreens wäre sowas unter Umständen sehr fatal, da die Parent-Form ja dann auf Daten arbeiten will, die erst geladen werden. Ein anderes Problem wären Shortcuts, aber um das Problem habe ich mich noch nicht gekümmert. So viel zu meinen Gedankengängen bisher.

Daher eben auch die Idee, die Client Area zu "sperren", analog zu den Elementen auf einem Panel, die gesperrt sind, wenn ich Panel.Enabled auf False setze.