Showmessage oder auch Form.showmodal verschwindet manchmal hinter Form

[Poolspieler]

Hallo zusammen,
manchmal kommt es vor, dass ein simples showmessage('bla'), oder auch ein mein_Fenster.showmodal; HINTER dem Hauptformular verschwindet.
Man hat dann (fast) keine Möglichkeit mehr, das Fenster in den Vordergrund zu holen.
Das Thema wurde 2006 hier http://www.delphipraxis.net/65588-me...ntergrund.html schon mal angesprochen - allerdings ohne so eine richtige Lösung.

Wenn ich anstatt form1.showmodal folgendes schreibe, dann scheint es nicht aufzutreten:

Code:

hauptform.enabled := false;
form1.show;
form1.bringtofront;

Dann muss man aber aufpassen, dass beim Schliessen von form1 das hauptform wieder auf enabled=true gesetzt wird...
form1 muss dann natürlich auf stayontop gestellt sein...
--> bei Anwendungen mit ganz vielen Formularen (die auch noch gleichzeitig offen sein können) wird das aber schnell recht kompliziert...

Es sieht so aus, als ob das Problem vor allem auftritt, wenn zwischen dem Button-Click und dem showmessage viel gemacht wird (z.B. umfangreiche Datei-IO, etc.).

Pseudocode:

Code:

procedure TForm.button1Click(Sender: TObject);
begin
  // Viel Datei-IO
  ...
  showmessage('ich bin fertig! Hoffentlich siehst Du diese Nachricht auch! Oder bin ich wohl versteckt?');
end;

Weiß jemand, woran das liegt - und was man vor allem dagegen tun kann?
Oder muss ich mir wirklich einen eigenen showmessage-Dialog basteln?

Gruß,

Poolspieler

[DeddyH]

Hilft dieser Thread evtl. weiter? http://www.delphipraxis.net/166408-m...de-wartet.html

[Poolspieler]

Hallo DeddyH,
vielen Dank für Deine Antwort!

Der Thread geht in die gleiche Richtung.
Aber eine wirkliche Lösung für das Problem habe ich nicht gefunden.

Wie sollte man messages (showmessage) ausgeben - muss man wirklich einen eigenen Dialog basteln?

Viele Grüße,

Poolspieler

[ChrisE]

Hallo Poolspieler,

ist Deine Angabe zu Deinem Nutzerkonto korrekt - also das du Delphi XE2 verwendest? Ich kenne das merkwürdige Verhalten von modalen Fenstern / Dialogen nämlich noch von Delphi 2007. Es scheint aber nicht mehr vorhanden zu sein bei Delphi XE2.

Dann aber noch etwas anderes, was mir gerade einfällt: Suche mal nach GhostingWindow bei google. Da gibt es ein ganz blödes verhalten von Windows, um nicht reagierende Anwendungen für den Benutzer zumindest minimal Bedienbar zu halten. Da du viel I/O erwähnt hast, könnte das der Fall sein bei Dir. Windows legt hier ein neues bedienbares Fenster für das vermeintlich "hängende" Fenster an und versteckt das echte hängende Fenster. Beim "zurück schalten" kann tatsächlich etwas schief gehen und der Dialog landet hinter dem Fenster. Das GhostingWindow-Problem beschränkt sich aber meines Wissens nach auf Windows XP. Kannst du ja mal suchen.

Gruß, Chris

[himitsu]

In ShowMessage stecken weitere Funktionen, da kann man sich den Message-Dialog erzeugen lassen und bevor man ihn anzeigt, könnte man noch etwas am PopupMode und PopupParent rumspielen und notfalls auch noch mit dem FormStyle.
z.B. könnte man sich die oberste Form suchen und den Dialog damit verbinden, damit Delphi den Dialog noch vor dieser Form darstellt.


Du könntest aber natürlich auch dafür sorgen, daß deine Anwendung garnicht erst hängen bleibt.
(z.B. Threads und Co.)

[Poolspieler]

Hallo Zusammen,
danke für Eure Antworten!

Ja, ich nutze Delphi XE2 Update4.
Unter Win7 habe ich das Problem (noch...) nicht gesehen.
Es tritt aber unter WinXP auf. Mit und ohne Delphi-IDE.

Meine Anwendung nutzt bereits Threads für die UDP-Kommunikation und allem was dazu gehört.
Jede kleine (oder auch größere...) Datei-IO und vor allem die Bedienung des UDP-Threads in einen Thread auszulagern fand ich nicht sinnvoll - oder liege ich da falsch?

Beispiel:

Code:

if OpenDialog.Execute then begin
  ...
  // Dateiinhalt auf konsistenz prüfen (CRC, etc.) --> dauert ca. 2 Sekunden
  if _fehler then begin
    showmessage('Es ist ein Fehler aufgetreten!'); // dieser Dialog bleibt manchmal im Hintergrund
  end;
end;

--> warum sollte man dies in einen Thread verpacken? Ist das nicht zu viel Aufwand?

Viele Grüße,

Poolspieler

[ChrisE]

Hallo Poolspieler,

ich glaube, dass es relativ wenig Aufwand ist bei XE2, eine vorhandene Methode in einem Thread ausführen zulassen. Man sollte nur irgendwie evtl. prüfen, ob hier VCL-Sachen gemacht werden. Und ein Versuch wäre es Wert.

Die Methode mit dem GhostingWindow heißt übrigens DisableProcessWindowsGhosting und das Problem existiert SEIT XP und nicht nur bei XP. In welchem Zusammenhang die Delphiversion steht, kann ich natürlich nicht sicher beantworten. Ich hatte damals große Probleme mit Delphi2007 und ein XE-Benutzer hatte die Probleme glaub ich nicht.

Gruß, Chris

[Poolspieler]

Hallo ChrisE,
vielen Dank für den guten Hinweis - so tritt das Problem (offensichtlich...) nicht mehr auf.

Hier der Code von http://stackoverflow.com/questions/1...odal-is-called:

Code:

procedure DisableProcessWindowsGhosting; 
var 
  DisableProcessWindowsGhostingProc: procedure; 
begin 
  DisableProcessWindowsGhostingProc := GetProcAddress( 
    GetModuleHandle('user32.dll'), 
    'DisableProcessWindowsGhosting'); 
  if Assigned(DisableProcessWindowsGhostingProc) then 
    DisableProcessWindowsGhostingProc; 
end;

"Dumme" Frage:
Welche tolle Möglichkeit hat man denn unter XE2 eine beliebige Routine in einem eigenen Thread laufen zu lassen?
Vor allem, wenn man trotzdem synchronisiert z.B. showmessage nutzen muss?

Gruß,

Poolspieler

[taveuni]

Zitat von Poolspieler:

Welche tolle Möglichkeit hat man denn unter XE2 eine beliebige Routine in einem eigenen Thread laufen zu lassen?
Vor allem, wenn man trotzdem synchronisiert z.B. showmessage nutzen muss?

z.b. anonyme Prozeduren in anonymen Threads

Delphi-Quellcode:

procedure MySynchProcedure(Param1: String; Param2: TObject; Param3: TDictionary<Integer, TMyObject>);
begin
  TThread.Queue(Nil,
  procedure
  begin
    // do anything synchronized here
  end);
end;

procedure DoAnythingTimeConsuming;
var
  Thrd: TThread;
begin
  Thrd: TThread.CreateAnonymousThread(
  procedure
  begin
    // do anything time consuming stuff here
    sleep(100000);
    
    MySynchProcedure(Param1, Param2, Param3);
  end);
  Thrd.FreeOnTerminate:= True;
  Thrd.Start;
end;

[ChrisE]

Hallo,

genau sowas, wie das Beispiel von taveuni hab ich gemeint.

Und das jetzt das DisableProcessWindowsGhosting funktioniert, zeigt ja, dass hier etwas stattfindet im Mainthread, dass eigentlich ausgelagert werden sollte in einen Thread. Denn es blockt den Mainthread so sehr, dass Windows denkt, die Anwendung wäre abgestürzt bzw. würde fest hängen.

Gruß, Chris