Zitat von
jbg:
Zitat von
Assertor:
über andere Ansätze (InstallationExcellence z.B.). Mit diesen Workarounds war es auch möglich, ein korrektes Verhalten zu implementieren.
Hast du das ausprobiert? 3D Flip und die Taskbar funktionierten damit, aber es gab einige Nebeneffekte, da das Hauptformular nun nicht mehr im z-order Stack des Application.Handle war.
Ja, hatte ich im produktiven Einsatz samt einiger eigenen Anpassungen. Damit war das Verhalten identisch zu anderen Anwendungen, z.B. Firefox (zweite Fenster z.B. von Favoriten-Library) und allem, was man täglich so im Einsatz hat.
Zitat von
jbg:
Zitat:
aber wenn es um den übliche Verhalten von Windows Fenstern geht, ist diese Lösung von MainFormOnTaskBar ein Bug.
Das sehe ich ganz anders. Das Verhalten von Delphi 1-2006 war nicht Windows-üblich. Mach mal in Word, Excel oder einer anderen MFC Anwendung deiner Wahl ein nicht-modales Fenster auf. Die liegen alle über dem Hauptfenster. Und warum ist das so? Weil dem CreateWindowEx ein HwndParent mitgegeben wird.
Mir ist das nie aufgefallen. Bei Delphi 2009 Anwendungen im Pre-Release Test aber sofort.
Zitat von
jbg:
Wenn du das verhalten unter Delphi 2007/2009 samt Windows Vista Unterstützung haben willst musst du CreateParams überschreiben und dort Params.ExStyle |= WS_EX_TOOLWINDOWS; und Params.WndParent := HWND_DESKTOP; einstellen.
Stimmt, Danke nochmal für den Hinweis. Habe ich direkt vor Deinem Post schon selbst eingebaut
Zum Glück hab verwende ich eine Form-Vorlage für sowas
Zitat von
jbg:
Zitat:
Es kann nicht sein, daß ein zweites Fenster trotz Aktivierung des MainForm im Vordergrund bleibt. Das entspricht nicht dem jahrelangen Look-And-Feel der UI. Punkt.
... nicht dem jahrelangen
Delphi Look-And-Feel der UI.
Ja, Du triffst - wie immer - den Nagel mit dem Kopf, äh auf den Kopf
Ja, das schicke Hidden App Window und Form Behaviour. War bestimmt auch toll für etwas vor oder um Win95 herum. Inzwischen sollte das mal gehörig redesigned werden.
Das grundlegende Änderungen möglich sind, zeigt ja Delphis .NET Geschichte. Oder
BDE, Interbase, oder, oder...
Trotzdem vielen Dank fürs Brainstorming. Dein Ansatz ist das, was ich jedem empfehlen würde, der vor diesem "Problem" steht bzw. damit durch Kunden konfrontiert wird. Wie so oft entstehen Pseudo-Standards durch Gewöhnung, Anwendungen die hier aus der Reihe tanzen fallen auf - nicht immer positiv. Mit dem Überschreiben von CreateParams läßt sich für wichtige, untergeordnete aber sachlich eigenständige Forms eine eigene Desktop-Zugehörigkeit erreichen.
Zusätzlich ließe sich per WS_EX_APPWINDOW ja noch ein eigener Taskbar Button dafür spendieren, ich nutze daher
Params.ExStyle := Params.ExStyle and not WS_EX_TOOLWINDOW or WS_EX_APPWINDOW;
im CreateParams override.
Das reicht mir und hilft vielleicht allen, die ebiges wollen.
Gruß und herzlichen Dank,
Assertor
