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;

zusammenfalten · markieren

Delphi-Quellcode:

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;

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.

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

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

Zitat von OldGrumpy:

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

Der Fall ist bereits geschildert und liegt als nicht reproduzierbar erst mal auf Halde.

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

Zitat von dataspider:

Wenn ich nach dem Close ein While Referenzzähler > 0 einbaue, geht gar nichts mehr.

Eine ungefilterte Spontanidee - man möge mir das um diese Uhrzeit verzeihen, wenn das Blödsinn ist - bei "warten" denke ich zuerst immer an einen Timer.
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?

@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

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
Eine Lösung, die ohne sowas auskommt, bevorzuge ich.

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

Versuche mal

sleep(0);

Zitat von bluesbear:

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
Eine Lösung, die ohne sowas auskommt, bevorzuge ich.

Das bestätigt mich in meinen Vermutungen oder Beobachtungen.
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