![]() |
Fenster ungefragt immer vor Hauptfenster - warum?
Seltsam!
Ich hab hier ein frisches leeres Testprojekt angelegt und folgenden Code:
Delphi-Quellcode:
Das erzeugte Fenster ist immer vor dem Haupfenster. Eh nicht schlecht, aber warum?
procedure TForm1.Button1Click(Sender: TObject);
begin with TForm.Create(self) do Show; end; Und seit wann ist das denn so? Aber, am aller wichtigsten: Was könnte der Grund sein wenn das bei einer Anwendung plötzlich nicht mehr der Fall ist? |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Alles (alle VCL-Forms) ist "standardmäßig" immer vor der Hauptform ... ist schon seit einer Weile so, also mindestens seit D2009. (in D7 war's noch nicht)
Du kannst aber ![]() ![]() ![]() [edit] Du kannst auch mal Folgendes ausprobieren:
Delphi-Quellcode:
pmNone
procedure TForm1.Button1Click(Sender: TObject);
begin with TForm1.Create(self) do begin PopupMode := pmExplicit; PopupParent := Self; Top := Self.Top + 25; Left := Self.Left + 25; Self.Tag := Self.Tag + 1; Caption := Self.Caption + ' PopupForm' + IntToStr(Self.Tag); Show; end; end; procedure TForm1.Button2Click(Sender: TObject); begin with TForm1.Create(self) do begin Top := Self.Top + 25; Left := Self.Left + 25; Self.Tag := Self.Tag + 1; Caption := Self.Caption + ' Form' + IntToStr(Self.Tag); Show; end; end; Zitat:
|
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Zitat:
Die Historie von dem Problem war glaube ich folgende: 1) Alle Delphi-Formulare hatten früher als zOrder-Parent das Application.Handle. 2) Windows hat mit mit einem XP-Servicepack das zOrder-Verhalten geändert Bei zwei Fenstern mit gleichem zOrder-Parent kann sich die Reihenfolge auf dem Bildschirm ändern. (Ein modaler Dialog kann also auch mal hinter einem anderes Formular wandern)... -> die VCL, insbesondere Dialogs.pas hat also nicht mehr recht funktioniert. Seither muss man die Handles der Parent-Formulare selber verwalten. In D7 verwende ich als Fix für die z-Order Probleme oft folgendes:
Delphi-Quellcode:
Der Code sagt dem Formular, dass es sich über den Owner hängen soll, und wenn kein Owner da ist hängt es sich über das gerade aktive Formular (falls eins da ist)).
procedure TMyForm.CreateParams(var Params: TCreateParams);
begin inherited CreateParams(Params); if (Parent <> nil) or (ParentWindow <> 0) then Exit; // must not mess with wndparent if form is embedded if Assigned(Owner) and (Owner is TWinControl) then Params.WndParent := TWinControl(Owner).Handle else if Assigned(Screen.ActiveForm) then Params.WndParent := Screen.ActiveForm.Handle; end; |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Die HauptForm ist eindeutig.
Das ist die, welche in Application.MainForm drinsteht und standardmäßig ist das die zuerst erstellte Form (über Application.CreateForm). Wenn noch (wieder) keine Form exisitert, bzw. grade nichts bei Application.MainForm drinsteht, und eine neue Form erstellt wird, dann wird diese automatisch zur Hauptform. Also meistens ist es das erste
Delphi-Quellcode:
in der DPR, bzw. die erste Form, welche in den Projektoptionen bei "Formulare > Automatisch erzeugen" auftaucht.
Application.CreateForm(T..., ...);
Also praktisch macht Delphi nun das automatisch, was dein CreateParams machte. Dialoge werden meistens auch an das aktive Form gehängt. Wobei wir da aktuell in Problemchen hatten. :cry: - wärend der Abarbeitung wurde eine Progressform angezeigt - diese Progressform wurde am Ende, bzw. bei einem Fehler (Exception) wieder ausgeblendet - Exceptiondialoge und Query-Dialoge verschwanden dann urplötzlich Grund: Diese hängten sich an die aktive Form, was die ProgressForm war und zusammen mit der ProgressForm wurden auch alle Dialoge gleich mit geschlossen. :wall: |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Ich hab's!!
Der Eintrag Application.MainFormOnTaskbar := True; in der Projektdatei hat gefehlt. Mal sehen was das nun wieder für Sideeffects hat... Aber eine Frage hab ich noch. himitsu, wenn das Hauptformular das zuerst erzeugte Fenster ist, krieg ich dann mit so einem Code (->Splashscreen) Probleme:
Delphi-Quellcode:
(frmSplash wird in frmMain.OnShow freigegeben)
begin
frmSplash := TfrmSplash.Create(nil); frmSplash.Show; frmSplash.Refresh; Application.Initialize; Application.MainFormOnTaskbar:=True; Application.ProcessMessages; Application.CreateForm(TfrmMain, frmMain); ... Application.Run; end. Da ist ja dann der Splashscreen das zuerst erzeugte Formular. Oder rückt das MainForm nach wenn der Splashscreen freigegeben wird? Danke! |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Du bekommst Probleme! Die Splashform muss nach dem Hauptformular erzeugt werden, du kannst aber das Hauptformular unsichtbar erzeugen, dann den Splashscreen und mit dem Schließen vom Splashscreen machst du das Hauptformular sichtbar. Setze ich selber so ein, funktioniert!
Viele Grüße Sybok Factor |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Wenn die Spalshform nicht über CreateForm erstellt wird, sollte sie sich nicht als MainForm registrieren und es dürfte IMHO keine Probleme damit geben.
|
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Zu einem Splashscreen hatte ich gerade einen netten Effekt:
- mein Splashscreen ist fsStayOnTyp - wenn man jetzt irgendwann zwischen Splashscreen.Show und Splashscreen.Hide zu einer anderen Anwendung wechselt passiert folgendes: -> die ganze Anwendung ist auf einmal immer über allen anderen Programmen Workaround: immer warten bis der Splashscreen weg ist... Fix im Code: Splashscreen.Free einfügen... ?!???? |
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Zitat:
|
AW: Fenster ungefragt immer vor Hauptfenster - warum?
Das passiert, wenn man Application.MainFormOnTaskbar erst nach dem Erzeugen des Splashscreens setzt. Denn dann ist das Application-Window schon auf der Taskleiste. Also einfach als erstes (z.B. direkt nach dem begin) Application.MainFormOnTaskbar auf true setzen und dann funktioniert das auch korrekt.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:46 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