Bug? Delphi Anwendung automatisch in den Hintergrund

[Gremlin]

Hallo,


ich habe hier ein seltsames Problem und weiss nicht wie ich es schnell beheben kann (Delphi XE, Tokyo 10.2, Update 3)

Symptome:

Wird ein Formular zur Laufzeit erstellt, aber nicht angezeigt und ist in einer Actionlist die Standart-Action TSearchFind hinzugefügt worden, so wird beim Schließen des Suchdialogs, die Anwendung in den Hintergrund gesetzt (entsprechend auch TSearchReplace)

Projektinhalt:

2 x TForm (Main+Sample, nicht automatisch erstellen)
1 x TActionList
1 x Action TSearchFind
1 x TEdit

Todos:

- Über den ButtonClick wird die Sample TForm erstellt
- CTRL-F Suche im TEdit
- Schließen des Suchdialogs
-> Application im Hintergrund.


Vielen Dank

[jaenicke]

Zitat:

nicht automatisch erstellen

Dann dürfte das daran liegen, dass das Hauptfenster nicht als erstes Formular mit Application.CreateForm erstellt wurde und somit nicht als Hauptformular in der Anwendung bekannt gemacht wurde.

[TiGü]

Bitte Projekt zippen (DPR, PAS, DFM, ggf. DPROJ) und hier hochladen über den Button "Anhänge verwalten" unterhalb des Antwortfensters.

[Gremlin]

Brauch man eigentlich nicht zu zippen, es ist einfach durch die Beschreibung nachzubauen.

Meine Projektdatei sieht ganz normal aus, wird das 2. Form zur Laufzeit nicht erstellt oder wird die 2. Form angezeigt, dann wird die Anwendung auch nicht in den Hintergrund gestellt.

Delphi-Quellcode:

program Project2;

uses
  Vcl.Forms,
  Unit2 in 'Unit2.pas' {Form2};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm2, Form2);
  Application.Run;
end.

[TigerLilly]

Naja, du willst ja was, also mach für uns den Aufwand so gering wie möglich. Dann probiert das eher wer aus + gibt dir Feedback.

[Gremlin]

Ok, hier ist der Source, obwohl das Projekt sehr überschaubar ist

[jaenicke]

Ich hatte es vorhin auch schon kurz so wie geschrieben in ein Projekt gebaut und kann es auch mit Delphi 10.4 nachvollziehen.

Der Grund ist, dass in Vcl.Dialogs in der Funktion TFindDialog.Execute das Fenster für den TRedirectorWindow, über das hinterher der Fokus geschickt wird, mit EnumThreadWindows ermittelt wird. Da kommt dann das zweite unsichtbare Fenster heraus obwohl es nicht sichtbar ist.
Wenn du im Debugger nach diesem Aufruf in TRedirectorWindow(FRedirector).FFormhandle das Handle des ersten Formulars schreibst, funktioniert es korrekt, sprich dann bekommt dieses auch den Fokus.

Meiner Meinung nach liegt der Fehler hier in der Unit Vcl.Dialogs:

Delphi-Quellcode:

{$IF DEFINED(CLR)}
function GetTopWindow(Wnd: HWND; Mem: LParam):Bool;
{$ELSE}
function GetTopWindow(Wnd: THandle; var ReturnVar: THandle):Bool; stdcall;
{$ENDIF}
var
  Test: TWinControl;
begin
  Test := FindControl(Wnd);
  Result := True;
  if Assigned(Test) and (Test is TForm) then
  begin
{$IF DEFINED(CLR)}
    Marshal.WriteInt32(IntPtr(Mem), Wnd);
{$ELSE}
    ReturnVar := Wnd;
{$ENDIF}
    Result := False;
  end;
end;

Dort wird das Fenster als "TopWindow" zurückgegeben obwohl es gar nicht sichtbar ist. Leider weiß ich nicht wo diese Funktion sonst verwendet wird und habe auch gerade keine Zeit das zu prüfen. Vom Namen her würde ich aber annehmen, dass das so nicht korrekt ist.

Ich würde vermuten, dass es so korrekt ist:

Delphi-Quellcode:

  if Assigned(Test) and (Test is TForm) and Test.Visible then
//...

Ich weiß aber wie gesagt nicht wie sich das anderswo auswirken würde und ob die Funktion so gemeint ist wie ich es vermute. Das müsste erst geprüft werden bevor das als Bug gemeldet wird.

Andernfalls müsste in TFindDialog.Execute ein anderer Callback verwendet werden.

[TiGü]

Immer (!) ein in sich abgeschlossenes Beispielprojekt anhängen, dann wird dir eher geholfen und es erübrigt sich das Glaskugelraten.
Also so, wie TigerLilly es richtig anmerkte. Das spart dir ja auch selber Zeit, wenn du einfach etwas zippst, anstatt die Nachbau-Anleitung runter zu tippen.
Also ein doppelter Hauptgewinn für alle!

Ansonsten hast du die wahrscheinliche Ursache von jaenicke gut ergründet bekommen.
Ob es sich um einen wirklichen Bug handelt, sei mal dahingestellt, weil der hier im Beispiel skizzierte Anwendungsfall ja sinnlos ist bzw. nicht üblich.

Denn wenn man bspw. anstatt

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
begin
  TForm3.Create(self);
end;

eher sowas schreibt

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  Form3: TForm3;
begin
  Form3 := TForm3.Create(nil);
  try
    Form3.ShowModal;
  finally
    Form3.Free;
  end;
end;

Dann funktioniert das Focus setzen auf die Mainform ja wieder.

Ansonsten kannst du dich derart behelfen, indem du folgendes machst:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  Application.OnDeactivate := AppDeactivate;
end;

procedure TForm2.AppDeactivate(Sender: TObject); // beliebiger selbstgewählter Name
begin
  Self.SetFocus;
end;

[Gremlin]

Vielen Dank bisher

Soweit wie jaenicke war ich auch schon, ich wollte aber den Source nicht ändern, da ich nicht sicher weiss, welche Nebeneffekte auftreten könnten.
Leider darf das Formular nicht sichtbar gemacht werden, sonst gäbe es ja auch kein Problem

Derselbe Source funktioniert problemlos unter Delphi7 und das Problem ist erst nach einer Portierung auf DelphiXE aufgetreten.
Die Suche nach der Ursache (Action und TFindDialog) war wesentlich aufwändiger.

[jaenicke]

Ich habe mal nachgeschaut. Das GetTopWindow wird ausschließlich an dieser Stelle verwendet. Von daher würde ich es, unabhängig davon, ob man das umgehen kann, als Bug einstufen, dass dort unsichtbare Fenster berücksichtigt werden.

Denn das Erzeugen von unsichtbaren Fenstern ist ja nun nicht so ungewöhnlich. Das Problem tritt nämlich auch auf, wenn man einfach nur ein zweites Formular hinzufügt (und es auf automatisch erstellen lässt) und damit gar nichts macht! Das erklärt wie ich gerade verifiziert habe, auch das Problem, das wir beruflich in unserer eigenen Anwendung haben.

Ich werde einen entsprechenden Bugreport erstellen... Link folgt dann, vermutlich heute Abend.