MDI und benutzerdefinierte Stile

[JRadke]

Hallo!

Wenn ich meine MDI-Anwendung mit einem beliebigen vordefinierten VCL-Stil kompiliere, erhalte ich beim Anklicken des Minimieren-Buttons eines Child-Fensters einen Laufzeitfehler:

Im Projekt MyProject.exe ist eine Exception der Klasse EOSError mit der Meldung 'Systemfehler. Code: 1407.
Fensterklasse wurde nicht gefunden' aufgetreten.

Selbst, wenn ich nur das Delphi-Template für MDI-Anwendungen mit einem angewählten Style ausführe, werden die Fenster nicht mehr richtig gezeichnet (Hier kommt zumindest keine Laufzeit-Fehlermeldung).

In der Delphi-Hilfe steht nichts davon, dass VCL-Stile für MDI-Anwendungen nicht geeignet sind.
Mach ich da irgend etwas falsch?

Thanks.

[himitsu]

MDI ist leider mehr bissl tot.
Da wird seit Jahren/Jahrzehnten nicht mehr dran weiterentwickelt und grade neue Dinge (wie z.B. VCL-Styles) haben da öfters mal Bugs (werden damit nicht getestet), welche aber oftmals auch nicht mehr behoben werden, selbst wenn man sie meldet.

Besser wäre es, wenn du das Konzept durch was Anderes ersetzt. (oder das mit den Styles weg lässt)



Wir kämpfen auch seit Jahren immer mal wieder damit, aber diesen Fehler hatten wir noch nicht.
Allerdings nutzen wir auch nur die Designs von DevExpress.

Bei uns gibt es vor allem Probleme mit dem Fokus, der beim Schließen von Fenstern gern kurz verschwindet und dann das ganzen Programm im Hintergrund landet.
Leider dürfen sich Programme im Windows nicht mehr selber in den Vordergrund holen (SetFocus/SetActiveWindow/...), wenn sie vom "jetzt" aktiven Programm nicht die Berechtigung dazu haben, was sie natürlich fast nie bekommen, außer das andere Programm ist von uns. (bzw. wenn sie dieses neue Programm selber gestartet haben und sich dabei das Recht selbst einräumen)
Somit muß man kämpfen den Fokus garnicht erst zu verlieren.

[JRadke]

Danke,
das ist zwar nicht die Antwort, die ich erhofft hatte, aber immerhin weiß ich jetzt, woran ich bin.
Am Einfachsten für mich ist es deshalb tatsächlich, die Styles einfach weg zu lassen.

Ich hab das mit der minierten Anwendung übrigens auch mal probiert.
Man bekommt die Anwendung mit

Delphi-Quellcode:

  
Application.Restore;
Application.BringToFront;

wieder hoch, allerdings scheint Windows keine Nachricht zu senden, wenn das Fenster minimiert wird.
Mit einem Timer klappt es jedenfalls bei mir.

Danke nochmal für die Antwort.

[himitsu]

BringToFront mag zwar gehen, aber es hilft nichts, wenn die Anwendung dennoch keinen Fokus (zurück)bekommt.

Ist eine Schutzfunktion für den Benuzer, welcher in Windows 10 (oder schon 8) eingebaut ist, damit kein "böses" Programm sich aktivieren kann und z.B. der Nutzer "Ausversehn" darin etwas bestätigt, weil er grade in einem anderen Programm, geistig schon halb weggetreten, mit [Enter] tausende Fenster/Dialoge bestätigt und urplörtlich ein fremdes Fenster vorhuscht.


Es gibt an Application eine Message/Event, wenn die Anwendung minimiert wird.
Wenn sie aber "nur" den Fokus verliert und nach hinten rutscht, dann natürlich nicht, aber da muß man sich eben an die FocusChange-Events des Screen (Screen.OnIrgendwas) hängen.



Das passiert z.B. gern, wenn ein Dialog oder ShowModal geschlossen wird, und zwischenzeitlich neue Fenster im Programm aufgingen, oder geschlossen wurden,
bzw. wenn man z.B. im OnClose ein anderes Fenster öffnet, aber Dieser erst kurz nach dem Hide/Free den Fokus bekommen wollte, wo dann für einen Bruchteil einer Sekunde Delphi nicht weiß, welchem Fenster es den Fokus geben will, dann geht der Fokus an NIL und das Programm verschwindet in den Hintergrund.

Delphi merkt sich das Fenster, was vor dem ShowModal/ShowMessage aktiv ist, und wenn dieses Fenster beim Schließen weg plötzlich ist, dann geht der Fokus gern verloren.
Es wäre schlauer, wenn es dann das nächste vorhandene aktivierbare eigene Fenster nehmen würde, aber so schlau ist Delphi nicht.