BeginThread inkompatibel zu CreateMessageDialog?

[d7user1]

hallo, ich erstelle mit mit 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 von Zacherl:

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe.

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

[Zacherl]

Zitat von uligerhardt:

Zitat von Zacherl:

Trotz weit verbreiteter Fehlannahme ist die WinAPI nicht komplett threadsafe.

Wobei 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 von 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.

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

Zitat von himitsu:

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.

[Bernhard Geyer]

Zitat von Zacherl:

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.