BeginThread inkompatibel zu CreateMessageDialog?

[d7user1]

hallo, ich erstelle mit mit

Delphi-Quellcode:

CreateMessageDialog)

einen eignen Message Dialog.
wenn ich aber einen Thread mit BeginThread (generell aus einem Thread) starte und dieser Thread eine Prozedur aufruft welche einen
eigenen Message Dialog enthält dann vergrößert sich die schrift des Dialogs ungefähr auf das doppelte.

ohne thread (aus dem VCL-Thread heraus) gibt es keine probleme.

wie kann ich das ändern? oder wie setze ich den Dialog zurück dass die "Msg" (Labels?) wiede eine normale schriftgröße hat?

[Zacherl]

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe. Ich vermute hier hast du eine Stelle erwischt, bei der dies der Fall ist. Man fährt aber mal davon abgesehen generell auch immer besser, wenn man die komplette GUI in einem einzigen Thread ablaufen lässt und nur die Business Logik in externe Threads auslagert.

[d7user1]

ok gut zu wissen, schade.

GUI = VCL => im VCL-Thread? und Business-Logik = procedure und functionen => externe Threads?

[Zacherl]

Jap genau. Normalerweise gibt es einen Thread mit der Message Queue (in Delphi der VCL Main Thread), welcher die GUI steuert. Alles was du an zeitaufwändigen Berechnungen sonst noch anstellen willst, kannst du in einen extra Thread auslagern. Wenn du darin eine Fortschrittsanzeige oder ähnliches aktualisieren willst, musst du das per Synchronize() Methode mit dem Main Thread synchronisieren.

[uligerhardt]

Zitat:

Zitat von Zacherl (Beitrag 1252343)

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe.

Wobei

Delphi-Quellcode:

CreateMessageDialog

aber eine VCL-Funktion ist. Und die VCL ist so gut wie gar nicht threadsicher.

[Bernhard Geyer]

Zitat:

Zitat von Zacherl (Beitrag 1252343)

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe.

Nicht komplett ist gut. Alle Win-GUI-Handles dürfen nur im erstellenden Thread verwendet werden.

[Zacherl]

Zitat:

Zitat von uligerhardt (Beitrag 1252348)

Zitat:

Zitat von Zacherl (Beitrag 1252343)

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe.

Wobei

Delphi-Quellcode:

CreateMessageDialog

aber eine VCL-Funktion ist. Und die VCL ist so gut wie gar nicht threadsicher.

Ja, das ist mir später dann auch aufgefallen. Hatte es fälschlicherweise für CreateDialog gehalten, wobei es auch bei dieser Funktion wohl schwierig bis unmöglich wird, die Message Queue und den API Aufruf in zwei verschiedenen Threads zu haben.

[himitsu]

Wenn man in dem Thread eine eigene Behandlung der Message-Queue implementiert und die Formulare/Dialoge (WinAPI) dort erstellt und verwaltet, dann gibt es fast keine Probleme.

(außer wenn dabei wieder globale Instanzen von z.B. Fonts us anderen Threads verwendet würden)



Und, auch wenn ich das hier vor Kurzem irgendwo gelesen hatte, man kann einen (neuen) Thread an einen anderen Desktop binden (wenn er vorher noch nie mit einem Desktop verbunden war), womit man darin also auch Fenster erstellen könnte, welche nicht auf dem aktuellen Benutzerdesktop liegen. (wie z.B. der Sicherheitsdesktop vor UAC oder beim Strg+Alt+Entf)

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1252409)

Wenn man in dem Thread eine eigene Behandlung der Message-Queue implementiert und die Formulare/Dialoge (WinAPI) dort erstellt und verwaltet, dann gibt es fast keine Probleme.

Ja genau. Wenn jeder Thread seine eigene Message Queue besitzt geht bei reiner WinAPI Verwendung alles klar.

Zitat:

Zitat von himitsu (Beitrag 1252409)

Und, auch wenn ich das hier vor Kurzem irgendwo gelesen hatte, man kann einen (neuen) Thread an einen anderen Desktop binden (wenn er vorher noch nie mit einem Desktop verbunden war), womit man darin also auch Fenster erstellen könnte, welche nicht auf dem aktuellen Benutzerdesktop liegen. (wie z.B. der Sicherheitsdesktop vor UAC oder beim Strg+Alt+Entf)

Ist zwar etwas OT, aber weißt du noch, wo du das gelesen hast? Hatte mit dieser API mal rumgespielt, um meinem Service zu ermöglichen, ein Fenster auf dem Benutzerdesktop anzuzeigen, aber hatte recht wenig Erfolg. Kann aber auch sein, dass das ab Vista in dieser Form wegen Session Isolation, etc. nicht mehr funktioniert.

[himitsu]

Keine Ahnung.

Via SetThreadDesktop kann man jedenfalls den Desktop umschalten, aber nur, wenn vorher noch keine Komponente (CreateWindow und sowas) in diesem Thread erstellt wurde. Egal, ob die inzwischen noch existieren, oder ob sie schon wieder freigegeben wurden. (Vermutung: Beim ersten Erstellen wird die Queue eingerichtet beim Umschalten darf es noch Keine geben)

Bei Services, sind die, seit einer Weile, vom Desktop getrennt und man muß beim Service, oder beim Installieren des Service, explizit angeben, ob der Service Interaktionen mit dem Benutzer machen darf. (also z.B. Dialoge anzeigen)
Ansonsten ist das dem Service einfach verboten.

Und bei SetThreadDesktop steht auch noch "desktop apps only".


Im Prinzip kann man so einen Thread starten, darin erstellt man einen eigenen Desktop, switcht den Thread auf diesen Desktop um, erstellt ein Fenster
und kann nun den Desktop umschalten. (danach Desktop wieder zurückschalten und natürlich Dialog und Desktop löschen)
Und schon hätte man seinen eigene "geschützten" Desktop, für z.B. eigene "sichere" Benutzerrückfragen, welche nur vom Benutzer gelesen und bedient werden können und nicht von irgendwelchen "bösen" Anwendungen, wenn man anderen Anwendungen/Threads den Zugriff auf diesen Desktop verbietet.