10.3.1: OnActivate wird vor OnCreate ausgeführt

[Bbommel]

Hallo Lieblingsforum,

ich habe mir jetzt auch mal Delphi Rio Update 1 angesehen. Beim compilieren meiner Hauptanwendung ist mir dabei ein merkwürdiger und sehr lästiger Effekt aufgefallen: zur Initialisierung meiner Anwendung gibt es einigen Code im OnCreate und einiges im OnActivate des Hauptformulars der Anwendung. Im OnCreate werden einige essentielle Dinge initailisiert (Konfigurations-Objekte erzeugt, Konfiguration gelesen und ähnliches), im OnActivate werden dann, wenn man sich darauf verlassen kann, dass alle Komponenten und ggf. zusätzlichen Formulare erzeugt sind, ein paar visuelle Einstellungen vorgenommen (das passiert natürlich nur beim ersten Aufruf von OnActivate).

Auch wenn es manchem jetzt in den Fingern juckt, eine Bitte: die Frage ist jetzt nicht, ob das ein geschicktes Design ist. :-)

Diese Konstruktion funktioniert nun aber so, seitdem es die Anwendung gibt, also seit mittlerweile mehr als 12 Jahren und sie hat somit auch schon so einige Generationen Delphi gesehen. Nun habe ich mich beim Testen aber eben gewundert, dass die Anwendung nicht richtig initialisiert wurde. Der oberflächliche Grund war schnell gefunden: das Ereignis OnActivate wird vor dem Ereignis OnCreate ausgeführt - damit sind einige Objekte noch gar nicht vorhanden, auf die in OnActivate zugegriffen wird.

Wenn ich eine komplett neue und ansonsten leere Delphi-VCL-Anwendung erstelle und den beiden Ereignissen eine Funktion zuweise (in dem Fall ein einfaches ShowMessage), dann ist die Reihenfolge der Ereignisse korrekt - erst Create, dann Activate.

Es muss also auf meinem Formular irgendetwas geben, das dafür sorgt, dass das "Activate" zu früh getriggert wird. Ich habe versucht, ein bisschen durch die Delphi-Units (Vcl.Forms, Vcl.ComCtrls) zu debuggen, aber irgendwann steig ich dann doch nicht mehr durch die Magie der VCL durch - auf den obersten Ebenen konnte ich zwischen 10.2.3 und 10.3.1 jedenfalls keine offensichtliche Änderung am Code feststellen. Das muss also irgendwo in den Tiefen der VCL passieren.

Aus meiner Sicht ist das erst mal ein Bug. Denn unabhängig davon, was ich alles an Komponenten auf das Hauptfromular geknallt habe, darf das ja nicht dazu führen, dass ein OnActivate vor einem OnCreate ausgeführt wird - hier ist ja auch die Reihenfolge in der Doku eindeutig beschrieben.

Habt ihr eine Idee, wie ich dem Ganzen weiter auf die Spur kommen kann? Könnte ich irgendwo den Moment abfangen, wenn das Activate in die Event-Queue geschrieben wird (oder was auch immer die da machen - es ist jedenfalls kein trivialer Aufruf eines "DoActivate", sondern im Aufruf-Stack steht vorher ganz viel mit "WndProc)? Wenn es tatsächlich ein Bug ist, würde ich schon gerne eine bessere Idee haben, was ich an Emba melden soll.

Ich würde mich über ein bisschen Hilfe sehr freuen.

[Delphi.Narium]

Wo ist das Ereignis OnActivate zugewiesen?

Im Objektinspektor?

Wenn ja, schmeiß es da raus und mach die entsprechende Zuweisung als letzte Zeile ins OnCreate.

Wird's dann besser?

Und nein, das ist keine professionell und durchdachte Lösung, sondern nur so 'ne Idee für: Hoffentlich geht's ;-)

[Der schöne Günther]

Sich darauf zu verlassen dass

Delphi-Quellcode:

OnActivate

nach

Delphi-Quellcode:

OnCreate

kommt, was ist da schlimm dran?

Ich hätte auch gesagt, der erste Schritt wäre herauszufinden warum OnActivate zu früh getriggert wird (z.B. mittels Debugger).

[Bbommel]

Wie gesagt, ob das schön ist oder nicht, soll jetzt nicht unbedingt das Thema sein. :-) Aus meiner Sicht sollte ich mich aber darauf verlassen können, da die Reihenfolge der Ereignisse auch explizit in der Doku erwähnt wird.

Der Vorschlag, das OnActicate erst am Ende von OnCreate zu setzen, hilft leider auch nicht (was ich zugegebenermaßen schon befürchtet habe). In dem Fall wird as OnActivate einfach gar nicht mehr ausgeführt (weil das Ereignis ja schon durch ist).

Wichtiger Hinweis noch: wie ich gerade gemerkt habe, tritt der Effekt nur in meiner Test-VM auf (Win 8.1, VMware Workstation Player 12). Aber: das mit 10.2.3 kompilierte Programm tut auch in der VM problemlos, das mit 10.3.1 nicht. Beide getestet auch außerhalb von Delphi.

Kopiere ich das mit 10.3.1 erzeugte Programm aus der VM auf meinen normalen PC, dann läuft es.

Vielleicht grenzt das ja das Problem für jemanden etwas ein.

Ich bin jetzt erstmal weg, mir raucht etwas der Kopf und ich brauche frische Luft... :-)

[Bbommel]

Kleiner Nachtrag: wie ich zur Not einen Workaround basteln könnte mit einer Statusvariablen, die bemerkt, dass das OnActivate vor dem OnCreate ausgeführt wurde, ist eigentlich auch klar. Mir geht es aber wirklich darum, irgendwie die Ursache herauszufinden, denn das finde ich schon ein bisschen merkwürdig, dass das passiert. Wenn sich dabei herausstellt: ja, ist halt so und ist auch erlaubt so und bisher hatte ich einfach nur "Glück", dann wird korrigiere ich natürlich mein Programm. Aber irgendwie habe ich bisher noch immer den Eindruck, dass das eigentlich so nicht passieren darf.

[hoika]

Hallo,
10.3 Community klappt wie erwartet, FormCreate vor FormActivate.

Ich würde es mal mit einem neuen leeren Projekt testen.

[Delphi.Narium]

Anderer Vorschlag:

Zuweisung des OnActivate aus dem Objektinspektor raus.

Im OnCreate ans Ende zuerst den Aufruf der OnActivate-Methode und dann das Ereignis zuweisen.

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender : TObject);
begin
  ...
  FormActivate(Sender);
  Self.OnActive := FormActivate;
end;

[Bbommel]

@hoika: Danke für die Rückmeldung. In einem leeren Projekt klappt es bei mir auch problemlos - hatte ich im Ursprungspost auch schon geschrieben. :-)

@Delphi.Narium: Ja, das wäre wohl der einfachste Workaround. :thumb:

Aber ich würde immer noch gerne die Ursache verstehen und ob es wirklich ein Fehler von mir ist oder ein Bug in der VCL.

[hoika]

Hallo,

Zitat:

Aber ich würde immer noch gerne die Ursache verstehen und ob es wirklich ein Fehler von mir ist oder ein Bug in der VCL.

Wo ist das Problem?
Binde deine verwendeten Komponenten immer weiter ein und finde die, die Murks macht.

Zitat:

Wenn ich eine komplett neue und ansonsten leere Delphi-VCL-Anwendung erstelle und den beiden Ereignissen eine Funktion zuweise (in dem Fall ein einfaches ShowMessage), dann ist die Reihenfolge der Ereignisse korrekt - erst Create, dann Activate.

Das hatte ich in dem vielen Text übersehen, sorry.


Diverse Fremdkomponenten erzeugen OnActivate (WM_ACTIVATE) an Stellen,
wo man sie nicht erwartet.
Fang mal bei TMS (TXXXDateTimePicker) an und hangel dich durch DevExpress.

Trail and Error

[Uwe Raabe]

Bist du sicher, daß es wirklich vor dem OnCreate aufgerufen wird oder eventuell auch innerhalb des OnCreate, noch bevor das fertig ist?

[Bbommel]

Zitat:

Zitat von hoika (Beitrag 1428319)

Hallo,

Zitat:

Aber ich würde immer noch gerne die Ursache verstehen und ob es wirklich ein Fehler von mir ist oder ein Bug in der VCL.

Wo ist das Problem?
Binde deine verwendeten Komponenten immer weiter ein und finde die, die Murks macht.

Ja, klar, das wäre die Notlösung. Das wird allerdings auch einiges an Bastelei, vielleicht würde ich dann doch einfach aufgeben und es halt doch einfach so hinnehmen. ;-)

Ich hatte gehofft, dass es eine Funktion aus den Standard-Units gibt, die benutzt wird, um das WM_ACTIVATE-Event anzulegen. Dann könnte man ja da einen Breakpoint reinsetzen und schauen, von wo aus das aufgerufen wird.

[Bbommel]

Zitat:

Zitat von Uwe Raabe (Beitrag 1428321)

Bist du sicher, daß es wirklich vor dem OnCreate aufgerufen wird oder eventuell auch innerhalb des OnCreate, noch bevor das fertig ist?

Ich hatte Breakpoints auf jeweils der ersten Zeile von meinem FormActivate und vom FormCreate. Die erste Zeile vom Activate wurde vor der ersten Zeile vom Create ausgeführt.

[Uwe Raabe]

Zitat:

Zitat von Bbommel (Beitrag 1428325)

Ich hatte gehofft, dass es eine Funktion aus den Standard-Units gibt, die benutzt wird, um das WM_ACTIVATE-Event anzulegen. Dann könnte man ja da einen Breakpoint reinsetzen und schauen, von wo aus das aufgerufen wird.

Das WM_ACTIVATE wird vom OS gesendet und kommt in der Anwendung in TCustomForm.WMActivate an. Es gibt meines Wissens keine Stelle, in der die VCL selbst ein WM_ACTIVATE absetzt.

Aber das WM_ACTIVATE löst den FormActivate Event gar nicht direkt aus. Dies geschieht in einer CM_ACTIVATE Message und diese wird an verschiedenen Stellen in einem Form ausgelöst: SetFocusedControl, ShowModal oder als Folge einer empfangenen WM_ACTIVATEAPP Message.

Gibt es vielleicht irgendwo einen Aufruf von Applicatition.ProcessMessages?
Welche Einstellung hat das Form-Property OldCreateOrder?

[Bbommel]

Hmh, es scheint so, als würde das Activate beim Fokussieren des PageControl auf dem Formular ausgelöst, und in den aufrufenden Funktionen davor passiert irgendwas mit einer Umrechnung wegen DPI. Ich vermute da irgendwo jetzt ein Problem vielleicht auch gerade im Zuammenspiel mit Win 8.1.

Um die Fragen noch zu beantworten:
OldCreationOrder ist false und war es auch immer. Aber auch ein Setzen von OldCreationOrder auf true ändert nichts - das Activate wird auch dann vorher ausgeführt.

Application.ProcessMessages kommt in meinem Programm an ein paar wenigen Stellen vor, aber nicht beim Initialisieren. Sicherheitshalber habe ich in die ProcessMessages aber auch mal einen Breakpoint gesetzt, um zu testen, ob es nicht doch schon versehentlich irgendwo aufgerufen wird. Wird es nicht.

Ich gebe die Ursachenforschung jetzt erst einmal auf - um das Formular Stück für Stück auseinanderzunehmen oder zu versuchen, noch tiefer in die VCL abzustiegen und rauszufinden, wo ein entscheidender Unterschied zwischen 10.2.3 und 10.3.1 ist, fehlt mir leider gerade die Zeit. Ich nehme es also erst einmal so hin, dass Activate und Create in umgekehrter Reihenfolge auftreten können und werde das mit Statusvariablen entsprechend abfangen (bzw. habe das in meiner 10.3-Spielwiese getan). Dann funktioniert das Programm ansonsten problemlos.

Danke für eure Anregungen!

[hoika]

Hallo,

Zitat:

beim Fokussieren des PageControl auf dem Formular

Den Fokus sollte man frühestens im OnShow, besser aber im OnActivate setzen,
weil vorher das Fenster (das eigentliche Windows-Fenster) noch gar nicht erzeugt ist.

[hoika]

Hallo,

Zitat:

Es gibt meines Wissens keine Stelle, in der die VCL selbst ein WM_ACTIVATE absetzt.

Die VCL nicht, aber diverse Fremd-Komponenten, z.B. der TAdvDateTimePicker.
Der schickt ein WM_ACTIVATE an sein Parent beim CloseUp seines Auswahlfeldes.

Ich habe mir deshalb angewöhnt, als erstes im FormActivate ein OnActivate=nil zu machen,
um die Ereignisbehandlung nicht mehrfach auszulösen.

[Uwe Raabe]

Zitat:

Zitat von Bbommel (Beitrag 1428365)

es scheint so, als würde das Activate beim Fokussieren des PageControl auf dem Formular ausgelöst

Das deckt sich mit meinen Erkenntnissen:

Zitat:

Zitat von Uwe Raabe (Beitrag 1428330)

Dies geschieht in einer CM_ACTIVATE Message und diese wird an verschiedenen Stellen in einem Form ausgelöst: SetFocusedControl

Zitat:

Zitat von Bbommel (Beitrag 1428365)

in den aufrufenden Funktionen davor passiert irgendwas mit einer Umrechnung wegen DPI.

In dem Bereich gibt es allerdings gravierende Unterschiede zwischen Rio und Tokyo.

[Bbommel]

Zitat:

Zitat von hoika (Beitrag 1428372)

Zitat:

beim Fokussieren des PageControl auf dem Formular

Den Fokus sollte man frühestens im OnShow, besser aber im OnActivate setzen,
weil vorher das Fenster (das eigentliche Windows-Fenster) noch gar nicht erzeugt ist.

Ja, das sehe ich genauso. :-) Falls das missverständlich war: dieses SetFocus vom PageControl ist auch nichts, was ich selber mache, sondern das passiert halt innerhalb irgendwelcher VCL-Routinen. Wie geschrieben: wenn ich es einigermaßen eingegrenzt habe, dann passiert es in der Folge irgendwelcher DPI-Geschichten.

Zitat:

Zitat von hoika (Beitrag 1428375)

Zitat:

Es gibt meines Wissens keine Stelle, in der die VCL selbst ein WM_ACTIVATE absetzt.

Die VCL nicht, aber diverse Fremd-Komponenten, z.B. der TAdvDateTimePicker.
Der schickt ein WM_ACTIVATE an sein Parent beim CloseUp seines Auswahlfeldes.

An Fremdkomponenten habe ich nur pgDAC und VST. Beide kommen aber im Hauptformular, um das es hier geht, nicht vor, pgDAC nutze ich auch sonst nur im Code und nicht als Komponente.

Zitat:

Zitat von Uwe Raabe (Beitrag 1428381)

Zitat:

Zitat von Bbommel (Beitrag 1428365)

es scheint so, als würde das Activate beim Fokussieren des PageControl auf dem Formular ausgelöst

Das deckt sich mit meinen Erkenntnissen:

Jepp, so war es auch gemeint. :-)

Zitat:

Zitat von Uwe Raabe (Beitrag 1428381)

Zitat:

Zitat von Bbommel (Beitrag 1428365)

in den aufrufenden Funktionen davor passiert irgendwas mit einer Umrechnung wegen DPI.

In dem Bereich gibt es allerdings gravierende Unterschiede zwischen Rio und Tokyo.

Ich meinte, das auch im Hinterkopf gehabt zu haben - Danke für die Bestätigung. Vielleicht sind es ja dann tatsächlich ungewollte Nebeneffekte der Änderungen in dem Bereich.

[hoika]

Hallo,
das sind aber doch seeeehr gravierende Änderungen, oha.

[Bbommel]

*** Update: ich konnte das Problem mit einer neuen, leeren Anwendung reproduzieren ***

Vorgehen: neue, leere VCL-Anwendung erstellen. Dem Form1 den WindowsState Maximized zuweisen. Die beiden Events OnActivate und OnCreate werden mit folgendem Code versorgt:

Delphi-Quellcode:

procedure TForm1.FormActivate(Sender: TObject);
begin
  ShowMessage('activate');
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  ShowMessage('create');
end;

Die Anwendung starten.

Ergebnis unter Win 8.1 in der VM: activate läuft vor create.
Ergebnis unter Win 10 ohne VM: create läuft vor activate.

Das is'n Bug, oder? Denn die Doku gibt die Reihenfolge der Events ja eigentlich vor (siehe hier: http://docwiki.embarcadero.com/Libra...mForm.OnCreate)

Vielleicht haben wir ja zusammen die Chance, es weiter einzugrenzen, in welcher Konstellation der Fehler genau auftritt. Falls jemand z.B. ein Win 8.1 ohne VM hätte, könnte man es ja mal da testen.

[Uwe Raabe]

Kann ich hier in einer 8.1 VM nicht reproduzieren. Kann es eventuell an den DPI-Einstellungen der Anwendung bzw. des Windows 8.1 in der VM liegen?

[Bbommel]

Das Win8.1 in der VM hat bei mir eine Skalierung von 125% eingestellt. Möglicherweise spielt das eine Rolle.

Kann heute nicht mehr testen, ob sich was ändern würde, wenn ich die auf 100% stelle - bin nicht mehr an dem Rechner.

[hoika]

Hallo,
und ohne WS_Maximized ?

[blawen]

Zitat:

Zitat von hoika (Beitrag 1428437)

Hallo,
und ohne WS_Maximized ?

Persönlich hatte ich auch diverse Seiteneffekte, wenn WS_Maximized gesetzt war (Objekt nicht initialisiert, Fenster wird ungewollt angezeigt, etc.).
Dies war bei mir aber auch schon bei 10.2.3 der Fall. Nach einspielen des High-DPI Patch's von Uwe war aber wieder alles wie gewohnt.

[Der schöne Günther]

Ich kann nicht viel hilfreiches beitragen außer zu bestätigen dass ich auch schon die merkwürdigsten Effekte hatte wenn ein Fenster zum Start direkt hätte maximized sein sollen. Ich habe es dann erst später im OnActivate maximieren lassen.

[DieDolly]

Zitat:

Das Win8.1 in der VM hat bei mir eine Skalierung von 125% eingestellt. Möglicherweise spielt das eine Rolle.

Trotzdem darf sowas nicht passieren. Ein sehr trauriger Bug ehrlich gesagt. Was anderes kann es doch gar nicht sein.

Zitat:

Nach einspielen des High-DPI Patch's von Uwe war aber wieder alles wie gewohnt.

Kann man den Patch auch irgendwie ohne Mercury und so einspielen?

Ansonsten muss man irgendwie noch einen Workaround bauen und im OnCreate ganz am Ende eine Statusvariable auf True setzen, auf die OnActivate dann warten muss und vorher passiert dann dort gar nix.

[Uwe Raabe]

Zitat:

Zitat von DieDolly (Beitrag 1428442)

Ein sehr trauriger Bug ehrlich gesagt.

Angesichts der Tatsache, daß er offenbar nur in ganz wenigen Umgebungen auftaucht (ich konnte ihn auf einem 150% Monitor immer nicht nachvollziehen), sehe ich das etwas zurückhaltender. Gerade im High-DPI Bereich gibt es so viele Konstellationen von Hardware, Windows Version (MS hat sich da auch nicht gerade mit Ruhm bekleckert und viele falsche Erwartungen geweckt) und Delphi Version, daß es nahezu unmöglich ist, alle Möglichkeiten auf Herz und Nieren zu testen. Wenn denn dann jemand so eine Kombination findet, bei der dieses Verhalten reproduzierbar ist, dann sollte man das entsprechend in QP einstellen. Also sicher kein Grund traurig zu sein :-D

[DieDolly]

Wenn man denn nicht wegen dem Bug traurig wird, ob es einer ist oder nicht, dann spätestens dann, wenn der Fix mal wieder Jahre auf sich warten lässt :cyclops:

[Uwe Raabe]

Zitat:

Zitat von DieDolly (Beitrag 1428446)

wenn der Fix mal wieder Jahre auf sich warten lässt

Die Wartezeit beginnt aber halt erst, nachdem ein QP Report mit reproduzierbaren Steps vorliegt.

[blawen]

Bei mir ist es relativ einfach nachstellbar:

- Neues Projekt
- 2 leere Formulare

Win10 mit 4k+HD Monitor (Mischbetrieb):
- Beide Formulare mit wsMaximized-> 2 Formulare werden geöffnet/angezeigt
- Form1 auf "wsNormal" und Form2 auf "wsMaximized" -> Form2 überdeckt Form1, Form2 kann aber nicht geschlossen werden

Wenn ich nur einen HD-Monitor angeschlossen habe, funktioniert es bei mir auch mit 10.3.1 wie erwartet.
Ebenso funktioniert es mit einer gepatchten 10.2.3 wie erwartet

[Uwe Raabe]

Zitat:

Zitat von blawen (Beitrag 1428450)

Win10 mit 4k+HD Monitor (Mischbetrieb):

Welche DPI hat der primäre Monitor?

[jaenicke]

Zu dem OnActivate...
Ich mache das schlicht so, dass ich darin dem Formular per PostMessage eine Nachricht schicke. Die wird dann verarbeitet nachdem es angezeigt wurde, egal wann das OnActivate aufgerufen wird.

[DieDolly]

Zitat:

Zitat von jaenicke (Beitrag 1428463)

Zu dem OnActivate...
Ich mache das schlicht so, dass ich darin dem Formular per PostMessage eine Nachricht schicke. Die wird dann verarbeitet nachdem es angezeigt wurde, egal wann das OnActivate aufgerufen wird.

Ich mache das im OnPaint so mit WMFormVisible. Ist Paint oder Activate besser?

[jaenicke]

Nun ja, OnPaint funktioniert natürlich auch, aber ein Event zu nutzen, das einen vollkommen anderen Zweck hat, widerstrebt mir schon sehr.

[DieDolly]

Ist OnActivate in Verbindung mit WMFormVisible denn in Ordnung und besser als OnPaint? (Code erst ausführen, wenn Form wirklich sichtbar ist)
Weil ich habe das gerade getestet. Showmessage in OnPaint und in OnActivate. Die Showmessage im OnActivate wird schon angezeigt, wenn das Form noch nicht sichtbar ist.

[HolgerX]

Hmm..

Wenn ich eine Behandlung brauche, welche erst ausgeführt wird wenn die Form sichtbar ist, dann mach ich das PostMessage im OnShow.
OnActivate habe ich bisher noch nicht verwendet.

Da OnPaint immer wieder aufgerufen wird, auch wenn nur ein Anderes Fenster kurz über das eigene gezogen wurde (es muss halt immer wieder neu gemalt werden), würde ich es nicht dort machen..

[DieDolly]

Zitat:

Wenn ich eine Behandlung brauche, welche erst ausgeführt wird wenn die Form sichtbar ist, dann mach ich das PostMessage im OnShow.

Das ist so nicht richtig.
Code der im OnShow ausgeführt wird, wird schon ausgeführt bevor das Formular sichtbar ist.

Das Formular ist erst im OnPaint sichtbar. Weder im OnShow noch im OnActivate ist es direkt nach Programmstart beim ersten Eventaufruf sichtbar. Testet es mal mit einer MessageBox.

Zitat:

Da OnPaint immer wieder aufgerufen wird,

Dafür setzt man dann auch eine Variable, damit genau das nicht passiert und Code initial dort nur einmalig ausgeführt wird.

[HolgerX]

Hmm..

Hab doch geschrieben '.. das PostMessage im OnShow'!

Zitat:

Zitat von DieDolly (Beitrag 1428509)

Zitat:

Wenn ich eine Behandlung brauche, welche erst ausgeführt wird wenn die Form sichtbar ist, dann mach ich das PostMessage im OnShow.

Code der im OnShow ausgeführt wird, wird aber schon ausgeführt bevor das Formular sichtbar ist.

Das Formular ist erst im OnPaint sichtbar. Weder im OnShow noch im OnActivate ist es sichtbar. Testet es mal mit einer MessageBox.

Dadurch wird diese Message erst nach Abschluss des OnShow und auch OnPaint ausgeführt....

[DieDolly]

Entweder habe ich mich verlesen oder es nicht ganz verstanden.
Welche Message schickst du genau im OnShow ab und wo behandelst du sie? Hier besteht für mich Lernbedarf.
Würde hier wie gesagt noch gerne was lernen.

[HolgerX]

Hmm..

Hier mal ein einfaches Beispiel.

Ich habe hier noch kein abgeleitetes Formular mit eigenem OnAfterShow...
Aber per Postmessage kommt hier nach OnShow und OnPaint das AfterShow.

Starte das Tool mal und verkleinere das Formular.. dann wird OnPaint wiederholt aufgerufen.
Würde nun das Postmessage im OnPaint aufgerufen, dann würde auch das OnAfterShow immer wieder aufgerufen werden.

Da das Postmessage jedoch im OnSHow gemacht wird, kommt dies nur einmal, da eigentlich OnShow wirklich nur einmal (je Form) aufgerufen wird.

(Erstellt mit D6.. ;) )