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

Delphi-Quellcode:

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:

Delphi-Quellcode:

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:

Zitat von s.h.a.r.k (Beitrag 1071407)

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:

Zitat von SirThornberry (Beitrag 1071410)

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:

Zitat von Assarbad (Beitrag 1071411)

Zitat:

Zitat von s.h.a.r.k (Beitrag 1071407)

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:

Zitat von s.h.a.r.k (Beitrag 1071413)

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.

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1071417)

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.

Und jetzt rate mal woran das liegt? ;)
Es sind Kindfenster. Nur daß hier dein Elternfenster das Formular wäre. Da du also Windows umgehen willst (weil nicht das Formular deaktiviert werden soll, sondern nur die Kindfenster), mußte es selber machen. Um EnumWindows wirste hier nicht herumkommen.

[s.h.a.r.k]

Aber das Panel selbst selbst Enabled der Unterkomponenten ja gar nicht auf False. Muss mir mal den Code dahinter anschauen, in der Hoffnung, ich finde die passende(n) Stelle(n).

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1071434)

Aber das Panel selbst selbst Enabled der Unterkomponenten ja gar nicht auf False. Muss mir mal den Code dahinter anschauen, in der Hoffnung, ich finde die passende(n) Stelle(n).

Ich weiß. Und wenn du dein Formular deaktivieren würdest, würde Windows es auch für dich übernehmen. Immerhin ist dann das gemeinsame Elternfenster (nämlich das Formular) deaktiviert, weshalb es auf die Kindfenster durchgreift.

Du willst aber ganz offensichtlich Windows und seine Mechanismen umgehen. Ansonsten hättest du wohl kaum das Panel so kategorisch ausgeschlossen. Dieses wäre ja wiederum ein gemeinsames Elternfenster für alle enthaltenen Elemente. Wenn du Windows austricksen willst, mußt du damit leben, daß du die Mechanismen selber nachimplementieren mußt. Ist nunmal so. Da wird auch eine lange Diskussion nix dran ändern :zwinker:

Das einzige was ich mir noch denken könnte, wäre irgendeine Schweinerei mit dem Formular während es geladen wird anzustellen und das Panel sozusagen zur Laufzeit zu injizieren. Aber auf Anhieb fiele mir dazu nicht mehr ein als im VCL-Code nachzuschlagen.

[s.h.a.r.k]

Das mit dem Panel habe ich ja nur ausgeschlossen, dass es sonst evtl. an gewissen Stellen krachen könnte, wie der Code oben andeuten sollte. Man soll die Overlay-Form ja nutzen können, ohne großartig seinen Code dafür anpassen zu müssen.

Aber auf die Dauer blende ich den Overlay echt modal ein. Was mich daran aber stört ist, dass ich die Parent-Form dann nicht mehr verschieben kann...