Application.ProcessMessages und Packages - Gibt es Probleme/Fallstricke?

[RSE]

Hallo,

ich arbeite das erste mal mit Packages. Die von mir verwendeten Packages werden zur Laufzeit dynamisch eingebunden. Nun habe ich gelesen, dass es in jedem Package ein eigenes Application-Objekt gibt. Daraufhin gebe ich einen Zeiger von Application-Objekt an jedes Package weiter, um z.B. ExeName und Terminate nutzen zu können. Soeben bin ich über mein erstes ProcessMessages gestolpert. Ich möchte hier alle anstehenden Messages abarbeiten, bevor ich weitermache. Dabei stellt sich mir die Frage, ob ich beim Aufruf

• mich auf das Application-Objekt der exe beschränken kann
• ProcessMessages aller Application-Objekte (in jedem Package und der exe) aufrufen sollte
• noch anders vorgehen muss

Als weitere Infos habe ich irgendwo gelesen, dass Application vor D7 oder so ein eigenes Fenster-Handle hatte und seitdem das Fenster-Handle des MainForm verwendet wird. Ich weiß weder was da dran ist, noch ob das eine Auswirkung auf meine Frage hat. Eigentlich sollte es ja eine Message-Queue pro Thread geben und ich gehe mal davon aus, dass die Packages im MainThread laufen. Demzufolge müsste ich mich auf das ProcessMessages des Application-Objekts aus der exe beschränken können, aber sicher bin ich mir eben nicht, weil ich nicht weiß, wie das alles intern läuft. Ich bin mir aber sicher, dass es hier im Forum Wissende gibt und hoffe, dass jeder, der etwas dazu beitragen kann sich auch traut, selbst wenn ies nicht gleich eine allumfassende Erklärung ist ;-)

p.s.: Ich arbeite mit Delphi XE

[jaenicke]

TApplication hat nach wie vor ein Fensterhandle. Der Unterschied seit Delphi 2009 ist, dass in der Standardeinstellung für neue Projekte dieses unsichtbare Fenster nicht mehr das ist, das du auf der Taskleiste siehst. Dafür gibt es die entsprechende Einstellung MainFormOnTaskbar.

Packages sharen genau Objekte, daher gehe ich mal davon aus, dass es auch nur ein Application-Objekt gibt und es ausreicht dieses zu benutzen. Das sollte sich aber ja auch leicht testen lassen.

[RSE]

Wow, ist es einfach auf sowas reinzufallen. Es war für mich so plausibel, dass es unterschiedliche Application-Objekte sind, dass ich es nicht überprüft hatte. Die Variable Application zeigt aber tatsächlich im package auf den gleichen Speicherbereich wie in der exe. Damit hat sich die Sache natürlich sofort erledigt. Danke für den Anstoß. Ich werde demnächst noch weniger glauben, was ich lese, und wenn es noch so plausibel erscheint :shock:

[RSE]

Bei weiteren Tests im Laufe des Tages kam es immer wieder zu sehr eigenartigen Zugriffsverletzungen. Zuletzt habe ich nun noch einmal die Variable Application untersucht. @Application (also die Variable selbst) und Pointer(Application) (also dort, wo die Variable hinzeigt, wo das Objekt liegt) haben beide den gleichen Wert in meinem Quelltext in der exe und in dem dynamisch geladenen Package. Es wird also tatsächlich die selbe Variable verwendet. Nun habe ich aber inzwischen auch Breakpoints in den Units der VCL, und dort ist weder die Variable noch der Wert der gleiche. Das heißt für mich, dass die Packages aus der requires-Klausel irgendwie anders/falsch eingebunden werden. Ich habe mich um diese Packages nicht weiter gekümmert - weder im Quelltext noch in den Einstellungen - und bin davon ausgegangen, dass Delphi das für mich macht. Ich habe alle benötigten bpl's im bin-Verzeichnis bei meiner exe, so wie das dann auch zum Einsatz des Programms sein wird.

Wie muss ich also die Packages aus der requires-Klausel einbinden, damit auch dort Application das selbe Objekt repräsentiert?

[RSE]

Ich habe jetzt doch endlich gefunden, wie man es richtig macht - und wie immer - schon funktionierts:
http://stackoverflow.com/questions/4...-time-packages
Also alle nicht selbstgebauten Packages statisch zur Runtime in die exe linken, damit überall die gleiche Version benutzt wird. Dann muss ich die zwar doch extra ausliefern und kann sie nicht als Ressource einbinden, aber das sind ja immerhin Dateien, die sich nicht ständig ändern, wie meine selbstgeschriebenen Packages, und die kann ich dann immernoch zur Laufzeit updaten :thumb: