Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (WinAPI, Konsole) » WindowProc + Haupt-Thread

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ]
000
07.08.2008, 15:38 Uhr
~Gast2008
Gast


Hallo Forum!

Ich habe eine Frage zu der WindowProc bzw. WNDPROC Methode...


Code:
LRESULT CALLBACK MyEventHandler(HWND Window, UINT EventMessage, WPARAM WParam, LPARAM LParam)


...mit der man die Nachrichten verarbeitet,
die Windows an das eigene Programm schickt.

Diese Callback Funktion wird ja nicht nur durch indirekte Nachrichten
aus der Warteschleife aufgerufen (welche mit Get/Peek/DispatchMessage
verarbeitet werden), sondern auch durch direkte Nachrichten die z.B.
Windows oder SendMessage schickt.

Jetzt meine Frage, wenn MyEventHandler durch so eine direkte Nachricht
aufgerufen wird, wird dann der aktuelle Haupt-Thread (main loop) einfach
so mittendrin in seiner Ausführung unterbrochen?

Oder läuft die WindowProc MyEventHandler dann in einem extra Thread ab?
So oder so könnte das ja zu Problemen führen, wenn in der WindowProc
Variablen verändert werden, auf denen auch der Haupt-Thread gerade
arbeitet, richtig?


Danke!!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
07.08.2008, 15:58 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat von ~Gast2008:

Diese Callback Funktion wird ja nicht nur durch indirekte Nachrichten
aus der Warteschleife aufgerufen (welche mit Get/Peek/DispatchMessage
verarbeitet werden), sondern auch durch direkte Nachrichten die z.B.
Windows oder SendMessage schickt.


Du schmeißt da einiges durcheinander. Get bzw. PeekMessage rufen nur Nachrichten für dein Programm bzw. Fenster ab. Das eine wartet halt auf eine Nachricht das andere nicht. SendMessage sendet eine Nachricht an ein Fenster und DispatchMessage ruft deine Window Procedure auf welche die Nachricht dann verarbeitet.

Soetwas wie "indirekte oder direkte Nachrichten" gibt es nicht. Nechricht ist gleich nachricht egal welche Anwendung die sendet.


Aus dem oben geschilderten Ablauf wird eigentlich schon ersichtlich das da nirgendwo ein neuer Thread aufgemacht wird denn wie gesagt wird deine WndProc einfach von DispatchMessage aufgerufen und das macht nicht einfach so nen neuen Thread auf.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
07.08.2008, 16:52 Uhr
~Gast2008
Gast


Hallo Guybrush,

das ist schon richtig was ich geschrieben habe. Das mit den indirekten und direkten
Nachrichten steht übrigens auch in dem Wälzer "Windows Programmierung" von
Microsoft Press.

Mit "Indirekte Nachrichten" werden die Nachrichten bezeichnet, welche in die
Nachrichten-Warteschlange eingefügt werden und dann im Get/Peek/Dispatch-
Message Loop verarbeitet und an die WindowProc geschickt werden.
So eine indirekte Nachricht kann man auch selbst via PostMessage() in die
Warteschlange einfügen.

Mit "Direkten Nachrichten" werden die Nachrichten bezeichnet, welche nicht den
Weg über die Warteschlange gehen, sondern DIREKT die WindowProc aufrufen.
Solche direkten Nachrichten können von Windows kommen, oder man kann sie
selbst vie SendMessage() abschicken.


Für die indirekten Nachrichten ist mir das schon klar, dass dort kein extra Thread
aufgerufen wird, weil die werden ja einfach durch den DispatchMessage Aufruf
abgearbeitet. Für die direkten Nachrichten ist das aber nicht so! Die können
eintrudeln wann immer sie wollen und rufen dann die WindowProc auf.
In einem anderen Forum wurde mir das auch schon bestätigt.

Gruß
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
07.08.2008, 17:07 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)


hmm ok hab gerade mal in der MSDN nachgeschat und das mit SendMessage wußte ich nicht. Trotzdem wird da kein neuer Thread aufgemacht weil das würde auch gar keinen Sinn machen und zu lauter Problemen (wie den von dir oben beschriebenen) führen.

Hier steht noch einiges dazu, aber auch nirgendwo das ein neuer Thread aufgemacht würde:
http://msdn.microsoft.com/en-us/library/ms644927(VS.85).aspx

In der SendMessage Dokumentation steht aber das das System wenn man eine Nachricht an ein Fenster aus einem anderem Thread schickt, zu diesem Thread wechselt und den sendenden so lange blockiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
07.08.2008, 17:17 Uhr
~Gast2008
Gast


Auf der von Dir verlinkten Seite werden übrigens die "indirekten Nachrichten"
als "Queued Messages" und die "direkten Nachrichten" als "Nonqueued Messages"
bezeichnet.

Meine Frage bezieht sich jetzt halt ausschließlich auf die "Nonqueued Messages",
welche ja im Prinzip einfach so reinplatzen und meinen eigentlichen Programmcode
(main loop) unterbrechen können (?).

Wenn man nämlich in der WindowProc Variablen verändert, auf denen der Main loop
gerade auch arbeitet, und die WindowProc kann durch Nonqueued Messages einfach
so irgendwann zwischendurch aufgerufen werden, dann muss ich diese Variablen
Thread Safe machen. Right? Btw wie geht das am besten mit der WinAPI, wenn
ich bestimmte Code stellen mutex machen will? Danke!!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
07.08.2008, 18:08 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat von ~Gast2008:
Auf der von Dir verlinkten Seite werden übrigens die "indirekten Nachrichten"
als "Queued Messages" und die "direkten Nachrichten" als "Nonqueued Messages"
bezeichnet.


ja hab ich gesehen.


Zitat von ~Gast2008:

Wenn man nämlich in der WindowProc Variablen verändert, auf denen der Main loop
gerade auch arbeitet, und die WindowProc kann durch Nonqueued Messages einfach
so irgendwann zwischendurch aufgerufen werden, dann muss ich diese Variablen
Thread Safe machen. Right?

und zum wiederholten male, nein weil kein neuer Thread erzeugt wird
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
07.08.2008, 20:45 Uhr
~Gast2008
Gast



Zitat von Guybrush Threepwood:

und zum wiederholten male, nein weil kein neuer Thread erzeugt wird



Selbst wenn kein neuer Thread erzeugt wird, dadurch das die WindowProc zu
jedem beliebigen Zeitpunkt den eigentlichen Programmcode unterbrechen
kann, wird es doch zu Problemen kommen können, wenn WindowProc und
der eigentliche Programmcode beide auf gleichen Variablen arbeiten.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
08.08.2008, 09:27 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)


Nein warum sollte es ?
Dieser Post wurde am 08.08.2008 um 09:29 Uhr von Guybrush Threepwood editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
08.08.2008, 16:03 Uhr
öni



Ich glaube Gast2008 meint das wenn er zum Beispiel in der main Funktion eine Variable hat z.B. i=10 und er mit dieser Variable arbeitet und sie manchmal auch verändern muss, und nun plötzlich durch ein nicht fest definierten Zeitpunkt vom System oder vom Benutzer eben WINPROC aufgerufen wird und diese eben auch in die Variable i eben was reinschreibt z.B. 20, dann ist es ja in der main verändert wenn er wieder drauf zu greifen möchte.

Ich glaube so hat er das gemeint, denke ich das doch mal.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
08.08.2008, 20:29 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)


Ja aber das ist normales Programmverhalten. Wenn ich in der WndProc bei einer bestimmten Nachricht i auf 20 setzte und dann plötzlich ein Problem habe weil i auf 20 ist da ja die Nachricht kam dann ist die Programmlogik falsch.
Dieser Post wurde am 08.08.2008 um 20:29 Uhr von Guybrush Threepwood editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ]     [ C / C++ (WinAPI, Konsole) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: