Windows, Threads - welche Funktionen führen zu SendMessage?

hustbaer

Windows aus verschiedenen Threads zu verwenden ist ja mit unter nicht unproblematisch.
Und zwar dann, wenn man in Thread X (X != Erzeuger des Fensters) etwas mit einem Fenster machen will, was intern zu einem SendMessage führt. Wenn man da nicht aufpasst, kann man schnell einen Deadlock basteln.

Dummerweise weiss ich nicht genau welche Funktionen dazu führen, dass intern eine Message (synchron) an den Erzeuger-Thread des Fensters geschickt wird.

Frage: kennt ihr Listen von Funktionen die a) bekanntermassen ohne solche Messages auskommen und daher unproblematisch sind bzw. b) bekanntermassen problematisch sind?

In einigen Fällen ist es mehr-oder-weniger klar. IsWindow() ist beispielsweise unproblematisch.
Etliche problematische Funktionen kann man daran erkennen dass in der MSDN etwas ala "... causes a ... message to be sent to the specified window or control" steht.

Aber wie sieht es z.B. aus mit GetWindowRect, GetClientRect, GetWindowInfo, GetParent, ClientToScreen/ScreenToClient, ...?

ps: und was wenn man sich einen Client-DC holen will? Kann man das problemlos aus einem anderen Thread?

Martin Richter

Es gibt dazu keine Liste.

Aber Du kannst zu 100% davon ausgehen, wenn es zu einer Aktion auch eine entsprechende Benachrichtigung gibt, dann hast Du ein Problem, z.B. SetFocus,WM_SETFOCUS oder GetWindowText, WM_GETTEXT.

Alle Funktionen, die Du genannt hast (GetWindowRect, GetClientRect, GetWindowInfo, GetParent, ClientToScreen/ScreenToClient) lösen keine Nachricht aus.

Allerdings frage ich mich, was Du mit einem CCLientDC willst. BTW: Ein ClientDC ist nichts anderes als ein DC der exakt auf das Fenster geclipped ist. Oder evtl. der DC, der für die Klasse oder das Fenster definiert wurde (Windows-DCs siehe Klassen Flags).

Solange es kein Klassen DC oder privater Fenster DC ist, kann man sich DCs besogren wie man will.

Nur ist mir nicht klar was es bringt einen DC in einem anderen Thread zu haben zu einem Fenster, dass sich selbst aber nur auf WM_PAINT im anderen Thread zeichnen soll...

HTH

hustbaer

Danke, damit kann ich schonmal was anfangen

Zur Erklärung:

Konkret geht es darum dass wir gerade eine Software gröber umschreiben die Videos darstellt.
Der Video-Player (DirectShow) ist dabei in einen eigenen Thread gewandert. Da drinnen wird der Filter-Graph gebaut, das Video positioniert, das Video gewechselt wenn eines aus ist etc. Eigener Thread macht auch Sinn, da das Filter-Graph bauen gerne mal 1-2 Sekunden dauern kann. Die Applikation soll in der Zeit allerdings "responsive" bleiben.

Ursprünglich haben wir den VMR7 im Windowed-Mode verwendet. Das hat nun aber Probleme gemacht, da wir als Parent für das Fenster des Players ein Fenster verwendet haben, welches im Main-Thread erstellt wurde. Und dann im "Player-Thread" das Fenster des Players als Child "attached" haben, und wieder "detached" uswusf. Was zu nem lustigen Deadlock geführt hat (eigene CRITICAL_SECTION im Player-Thread gelockt -> verstecktes SendMessage, selbe CRITICAL_SECTION gleichzeitig im Main-Thread gelockt -> kein Message-Dispatching mehr bis CS verfügbar -> deadlock).

Nun hab ich mich nach einer Lösung umgesehen, und es einfach mal mit dem Windowless-Mode des VMR7 probiert. Scheint gut zu funktionieren (die Deadlocks waren vorher so-gut-wie bei jedem Video-Wechsel, seit der Umstellung kein Problem mehr beobachtet). In der MSDN steht auch dass einer der Vorteile des Windowless-Mode der ist, dass man nicht so leicht nen Deadlock durch Window-Messages bastelt, da der Renderer eben kein eigenes Fenster verwendet.
Allerdings muss man immer noch das Fenster als "Clip Window" setzen, und da hab ich mich dann gefragt, ob selbst das wirklich so 100% problemlos ist. Oder ob es nur zu gehen scheint, weil an weniger Stellen Messages an das "Clip Window" gesendet werden.
Da der Player-Thread zum korrekten Clippen die sichtbaren Teile des Fensters ermitteln muss, wollte ich wissen, ob das wirklich ohne SendMessage geht.

Was die DC-Sache angeht: das war reine Neugier. Ich gehe davon aus dass der VMR7 keinen DC zum Rendern verwendet, aber wenn man selbst etwas ähnliches basteln wollte, z.B. ohne DirectDraw/Direct3D, dann würde man sich vermutlich einen DC zum Zeichnen des Videos besorgen. Daher die Frage ob das überhaupt problemlos möglich wäre.