MainForm immer hinten?

[himitsu]

In "neueren" Delphi-Versionen ist die MainForm immer hinten.
Also nur auf die Forms der eigenen Anwendung bezogen. Auf Fremdprogramme hat es keinen Einfluß.

Wird das in Zukunft (Win8) auch so bleiben und funktioniert das auch in allen Windows-Versionen so? (vorwiegend ab Win2K/XP)
Man kann den Eingabefokus auf die MainForm geben und dennoch bleiben die ChildForms davor liegen.

Delphi-Quellcode:

// 'nen Button auf die Form und dann noch diese beiden Methoden rein

var
  FormCounter: Integer = 0;

procedure TForm5.FormCreate(Sender: TObject);
begin
  if (Self <> Application.MainForm) and (Application.MainForm <> nil) then begin
    Inc(FormCounter);
    Caption := (Owner as TForm).Caption + ' - Form' + IntToStr(FormCounter)
  end else
    Caption := 'MainForm';
end;

procedure TForm5.Button1Click(Sender: TObject);
begin
  (TComponentClass(ClassType).Create(Self) as TForm).Show;
end;

Grund: Wir haben ein Programm (war vorher in/bis D7 entwickelt) und dort wird noch über fsStayOnTop dafür gesorgt, daß die MainForm immer hinter den ChildForms liegt.
Leider hat fsStayOnTop einige Probleme, so daß z.B. manchmal irgendwelche Dialoge nicht sichtbar sind. Außerdem bereitet es beim Debuggen gerne mal Probleme, da die IDE auch nicht sichbar ist.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1150618)

Wird das in Zukunft auch so bleiben und funktioniert das auch in allen Windows-Versionen so? (vorwiegend ab Win2K/XP)

Das Verhalten kann ich unter XE2 nachvollziehen, wenn MainFormOnTaskBar := true gesetzt ist, sonst nicht. Ob das so korrekt ist, mag dahingestellt sein - das kann die allenfalls Embarcadero beantworten. Ich meine mich erinnern zu können, daß das schon seit D2007 so ist und ein QC dazu als "as designed" geschlossen wurde (kann ich aber gerade nicht finden). Insofern hast du gute Chancen, daß das so bleibt.

XE/XE2-Programme laufen soweit ich weiß eh nur ab Win2K oder gar XP.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1150618)

Wird das in Zukunft (Win8) auch so bleiben

Bisher sieht es dort ja genauso aus und ich glaube kaum, dass sich das in der RTM noch ändert. Zudem ist das ja vor allem von der Implementierung in Delphi abhängig. Schließlich hängt das ganze ja mit der Änderung des Application-Window zusammen (schrieb Uwe Raabe ja auch schon). Solange sich diese Implementierung (oder deine Einstellung in Delphi) nicht wieder ändert (warum sollte sie?), wird das auch weiter so funktionieren.

Zitat:

Zitat von himitsu (Beitrag 1150618)

und funktioniert das auch in allen Windows-Versionen so? (vorwiegend ab Win2K/XP)

Welche meinst du denn sonst? Aktuelle Delphiversionen unterstützen doch ohnehin erst Windows 2000 oder höher.

[himitsu]

Aktuell haben unsere Kunden wohl vorwiegend XEP und Win7.
Im Windows Server 2008 mit XE konnte ich das auch soweit bestätigen.

Im Prinzip ist es ja genau das Verhalten, welches für uns nötig ist. Das "as designed" wäre somit vollkommen OK. :thumb:
Wäre nur blöd, wenn man ein Programm nun umbaut, da es jetzt ja nativ geht und dann geht es in XE3, in einer 64 Bit-App oder in Win8 plötzlich nicht mehr. :?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1150633)

Wäre nur blöd, wenn man ein Programm nun umbaut, da es jetzt ja nativ geht und dann geht es in XE3, in einer 64 Bit-App oder in Win8 plötzlich nicht mehr. :?

Naja, es ist ja nicht so, dass man das Verhalten nicht auch schon in Delphi 7 hätte bauen können. Es war nur der entsprechende Aufwand nötig die ganzen Fensterstile umzubauen und noch ein paar andere Tricks. Zur Not könnte man das bei neueren Delphiversionen ja genauso. Aber das wird wohl kaum nötig werden. ;-)

[Codewalker]

Die Reihenfolge von "gestapelten" Fenstern kann man doch seit einigen Versionen mit

Delphi-Quellcode:

Form.PopupParent

kontrollieren und Einfluss darauf nehmen. Damit sollte das Verhalten von himitsu abbildbar sein.

[himitsu]

Bei dem Namen PopupParent wäre ich nie auf sowas hier gekommen. :shock:
Aber sieht gut aus. :thumb:

[DSCHUCH]

ich habe auch festgestellt, das die neuen dialogforms diese probleme scheinbar nicht mehr haben.

TTaskMessageDialog.

die klassische CreateMessageDialog funktion verursacht diverse effekte.

und in Dialogs.MessageDlg wird ja automatisch die neue TaskMessageDialog aufgerufen, insofern man Windows Vista ff verwendet.