![]() |
Ersatz für Application.ProcessMessages
Hi,
ich bin gezwungen, in meiner Anwendung Application.ProcessMessages an einigen Stellen zu eliminieren, da genau dieses für sporadische Abstürze der DevExpress QuantumGrid beim Destroy von Formularen sorgt. Bisher hatte ich das Schließen der Anwendung so: Alle Formulare schließen; Application.ProcessMessages; Disconnect von der DB; oder Wechsel der Datenbank: Alle Formulare schließen; Application.ProcessMessages; ReConnect von der DB; Jetzt habe ich mir versuchsweise eine MethodenListe erstellt, welche ich z.B. bei Wechsel der DB füttere: In MethodenListe Methode für Schließen aller Formulare; In MethodenListe Methode für ReConnect;
Delphi-Quellcode:
In der überschriebenen Methode UpdateActions der Form (welche ja vom Idle der App abhängig ist) rufe ich nun eine Methode auf, welche immer die erste Methode aus der Methodenliste holt, den Eintrag aus der Liste entfernt und die Methode ausführt.
procedure TFRMMain.DoChangeConnection(Sender: TObject);
Var AMethod: TNotifyEvent; begin // Datenbank wechseln Application.ProcessMessages; if CanCloseEx then begin // Alles Fenster zu AMethod := CloseAllModules; FMethodList.Add(TMethod(AMethod)); // neu verbinden AMethod := ChangeConnection; FMethodList.Add(TMethod(AMethod)); end; end; procedure TFRMMain.UpdateActions; begin inherited; if (FMethodList <> nil) then HandleNextMessage; end; procedure TFRMMain.HandleNextMessage; Var AEvent: TNotifyEvent; begin // immer ein Event nach FIFO abarbeiten if (FMethodList.Count <> 0) then begin AEvent := TNotifyEvent(FMethodList[0]); FMethodList.Remove(TMethod(AEvent)); TNotifyEvent(AEvent)(Self); end; end; Der Wechsel der BD funktioniert erst mal so weit. Aber das Schließen wird schon komplizierter, da ich das im CloseQuery des Forms abfange und es wahrscheinlich gar nicht mehr zum Aufruf von UpdateActions führt. Gibt es eine elegantere Lösung? Ideal wäre etwas in der Art: Formular schließen; Warten, bis es komplett zerstört ist; Und jetzt weiter; Aber das eben ohne Application.ProcessMessages... Das Warten ist notwendig, da ich in den Formularen z.B. im BeforeDestruction noch alle möglichen Einstellungen in die DB schreibe. Warte ich nicht, ist die DB-Verbindung gekappt, während die Forms noch fleißig versuchen, ihre Einstellungen in die DB zu schreiben. Ich hoffe, mein Problem einigermaßen verständlich dargestellt zu haben. Ich brauche jetzt nicht den Hinweis, mich bitte an den Herstelle zu wenden etc. Ich brauche einen Workaround und möchte einfach nur wissen, ob und wie es evtll. besser geht. Danke, Frank |
Re: Ersatz für Application.ProcessMessages
Zum "Warten bis es komplett zerstört ist" könntest Du einen Referenzzähler verwenden der im jeweiligen Destruktor als allerletztes dekrementiert wird (im entsprechenden Ctor muss dieser dann als allererstes inkrementiert werden). Zum sicheren Inc/Dec siehe z.B. InterlockedIncrement/InterlockedDecrement (Win32 API). Erst wenn der Referenzzähler wieder null ist, sind alle Forms weg und du kannst die DB schließen/neu verbinden.
Nichtsdestotrotz ists ein Fall für den Hersteller wenn einem sporadisch bei 180 auf der Autobahn die Motorhaube abhanden kommt ;) Da sollte man zumindest mal anfragen, anstatt hier nach dem notwendigen Durchmesser für einen selber zusätzlich montierten Haltedraht zu fragen :) |
Re: Ersatz für Application.ProcessMessages
Zitat:
Das mit dem Referenzzähler mache ich schon. Aber was hilft mir das. Wenn ich nach dem Close ein While Referenzzähler > 0 einbaue, geht gar nichts mehr. Ich müsste wieder ein Application.ProcessMessages einbauen, damit dis Anwendung überhaupt weiter macht. Cu, Frank |
Re: Ersatz für Application.ProcessMessages
Zitat:
Ein Timer, der ermitteln kann, ob alle relevanten Fenster oder was auch immer zu sind, und dann eine Aktion auslöst (ein globales Flag setzen, ein PostMessage, o.ä.), die dann die nächste Aktion in Gang setzt? |
Re: Ersatz für Application.ProcessMessages
@OldGrumpy
ich hab im MSDN mal nach InterlockedIncrement, InterlockedDecrement gesucht. Es kann für die Stabilität der Anwendung durchaus von Nutzen sein, den Referenzzähler umzustellen. Ich mach das bis jetzt klassisch in einem ViewController. OK, ich könnte jetzt z.B. ein Event definieren und auslösen: OnLastFormClosed. @bluesbear An einen Timer habe ich auch schon gedacht. Immerhin arbeitet die Anwendung weiter und das Problem ist damit auf jeden Fall lösbar. Das ist dann eine Mischung aus den beiden Lösungsansätzen. Ich werde mal abwägen, ob Ereignis im ViewController oder Timer besser ist. Erst mal Danke für die Anregungen Frank |
Re: Ersatz für Application.ProcessMessages
Hi Dataspider,
wenn irgendwas geschlossen, zu gemacht oder beendet werden soll, führen meiner Erfahrung nach jegliche Application.ProcessMessages zu merkwürdigen timing-Problemen. Da kommt oft irgendwas in nicht nachvollziehbarer Weise durcheinander in der Reihenfolge. Nicht nachvollziehbar heißt: ich verstehe es nicht :wink: Eine Lösung, die ohne sowas auskommt, bevorzuge ich. |
Re: Ersatz für Application.ProcessMessages
Jetzt wo ihr das sagt, erinnere ich mich dunkel, auch schonmal so einen Fall gehabt zu haben... ich habs damals aber da es nur um das zuverlässige Beenden der Applikation (zwecks Update) ging, mittels TerminateProcess "gelöst" :) Unsauber, aber da der Prozess eh zum Update den Bach runter ging, so eben erträglich. Da ich momentan keine Zeit hab, die Randbedingungen auszuloten, unter denen das passiert, bleibt mir zumindest für jetzt nichts anderes übrig als mit dem Problem zu leben. Wenn jemand konkrete Hinweise hat, helfe ich gerne beim Einkreisen, aber eine Suche ins Blaue hinein passt momentan leider nicht in den Terminplan :(
|
Re: Ersatz für Application.ProcessMessages
Versuche mal
Delphi-Quellcode:
sleep(0);
|
Re: Ersatz für Application.ProcessMessages
Zitat:
Vielleicht hätte ich das Schließen der Anwendung verhindern sollen, wenn noch irgendwelche Datenmengen im State dsInsert / dsEdit sind. Aber nun haben sich die User daran gewöhnt, das ein Klick auf das X reicht. Dann evtll. noch Abfragen, ob gespeichert werden soll etc. Aber auf der anderen Seite wächst man doch mit jeder Herausforderung. Ich werde meinen Viewcontroller so umschreiben, dass er die einzelnen Module mit CloseAllModules kontrolliert nacheinander schließt. Nach Abschluss wird ein Event ausgelöst und dann kann ich Schliessen, Reconnecten etc. @hathor sleep(0) hilft hier nicht weiter. Cu, Frank |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz