[erledigt] Dialogfenster verschwinden im Hintergrund

[Carsten Hölscher]

Wenn man aus dem Willkommenfenster heraus einen Einstellungsdialog aufruft, dann ein anderes Windows-Fenster aus der Taskleiste in den Vordergrund holt, und dann wieder zu Zusi wechselt, verdrückt sich das Einstellungsfenster, bis man Alt-Tab gedrückt hat.

Anmerkung: Problem ist bekannt, aber noch keine Lösung.

Carsten

[Thomas U.]

Da es auch das Startfenster mit den Danksagungen betrifft:
Wenn man Zusi öffnet und das Fenster nicht wegklickt, sondern in ein anderes Programm und wieder zurück wechselt, verschwindet das Startfenster im Nirgendwo, kann nicht mehr in den Vordergrund geholt werden und Zusi lässt sich nurnoch über den Taskmanager beenden. Zudem wird Zusi in diesem "Zustand" zwar in der Taskleiste angezeigt, aber nicht in der Alt+Tab-Liste.

[Carsten Hölscher]

Ein paar mal Alt-Tab drücken hilft dabei normalerweise.

carsten

[Judith Montgomery]

Alt+Tab nützt bei mir (Windows 7, klassisches Aussehen – also ohne Aero) nichts, weil Zusi ja nicht in der Alt+Tab-Liste ist. Was aber hilft, ist folgendes: Den Mauszeiger über das Zusi-Symbol in der Taskleiste bewegen, warten, bis die Fenster-Liste erscheint (mit einem offenen Fenster), darin das Schließen-Symbol anklicken, und dann den Mauszeiger nochmal bewegen. Daraufhin wird nicht etwa Zusi beendet, sondern das verschwundene Dialogfenster springt wieder in der Vordergrund (ausprobiert mit dem Info-Fenster). Sehr kurios...

Judith

[Max Senft]

Hi Carsten,

eigentlich auf der Suche nach einer Lösung für das Taskbar Problem bin ich auf folgendes gestoßen:

Strange Activation

One side affect to the code introduced in the original article for fixing window animations and previews is that a form beneath another modal form can become visually active if its taskbar button is clicked. Note that this is just a visual discrepancy; you cannot actually interact with anything on the covered form. Max Pyatnitsky brought up this problem on the CodeGear newsgroups, and I thought I'd share a slightly modified version of his solution (this is also now included in the updated sample and compiled executable):

Code: Alles auswählen

procedure TMainForm.WMActivate(var Message: TWMActivate);
begin
  if (Message.Active = WA_ACTIVE) and not IsWindowEnabled(Handle) then
  begin
    SetActiveWindow(Application.Handle);
    Message.Result := 0;
  end else
    inherited;
end;

Thanks to Max Pyatnitsky for his solution to this problem. This passes the activation on to the hidden application form when our form is activated, ensuring any modal forms get focus properly.

Wäre cool, wenn du das bei einer Gelegenheit mal testen könntest. Vielleicht ist zumindest das Verdeckungsproblem dann gelöst.

Grüße
Max

[Mr. X]

Ich halte das hier nicht für [erledigt] - es sei denn, das soll sich auf die nächste Demoversion beziehen.

Aus Anlass dieses Threads habe ich die Demo 3.0.4.0 mal wieder gestartet, und mir ist aufgefallen, dass das furchtbare Fenster-Problem noch immer existiert.

Passiert nicht nur beim Programmstart-Dialog, sondern auch bei den Einstellungen, dem Eingabegerätedialog und sicherlich noch bei allen anderen Dialogen, die man irgendwie in Zusi öffnen kann.

Wird das in der kommenden Demoversion behoben?

[Alwin Meschede]

Wird das in der kommenden Demoversion behoben?

Ja. Deswegen war es als erledigt markiert.

[Mr. X]

Gut, danke. Hätte ja auch sein können, dass man Alt+Tab zur Problemlösung erklärt hat; Beruhigend, dass das nicht der Fall ist.

[Alwin Meschede]

Carsten behebt einen Bug und markiert den Issue unmittelbar danach als erledigt. Selber zu sehen bekommt man den Fix dann mit der nächsten veröffentlichten Version. So sieht der Workflow aus. Ist also nicht so, dass der Bug irgendwie für ungültig erklärt wurde oder so, weil ein noch bestehendes Problem plötzlich als erledigt da steht. Man könnte es sicherlich auch anders handhaben, aber im Testerkreis praktizieren wir das seit Jahren so.