Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (WinAPI, Konsole) » Warteschlange

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 <
000
21.06.2004, 16:10 Uhr
Groovejuice



Hallo,
ich habe da ein kleines Problem mit dem Senden und Empfangen von Nachrichten mit der Klasse WinSock. Senden klappt wunderbar, empfangen auch.
Ich bräuchte aber einen Tip wie ich diese Funktionen richtig in mein Programm einbaue.
Wenn ich eine Nachricht sende bekomme ich von meinem Zielsystem immer eine Antwort zurück. Mein Problem ist nur wie ich diese auswerte.

z.B wird bei ändern eines Reglers von meinem Programm etwas verschickt.

C++:
void Volume::OnCustomdraw_ChangeVolume()
{
UpdateData(TRUE);
SendeDaten(SEND_VOL, m_ctlVol_1.GetPos())
}



Ein Windows ereignis löst die Funktion EmpfangeDaten() aus wenn eine Nachricht zurückkommt.

Normalerweise Kommt jetzt vom Zielsystem ein OK zurück oder ein Fehlercode.

Würde ich jetzt nach dem Funktionsaufruf SendeDaten() eine while Schleife setzen um Auf eine Antwort zu warten wäre mein ganzes Programm damit beschäftigt auf eine Antwort zu warten und tut nichts anderes.

Gibt es eine Lösung in der der Rest meines Programmes weiterläuft und ich
trotzdem eine warteschlange habe ?

Wäre so etwas wie eine Zeitverzögerte Funktion

xxx Funktion (a, b)

a, b -> gesendete Parameter
Hauptprogrammteil läuft weiter.
xxx -> kommt nach einiger Zeit als Antwort zurück.



Ich hoffe ich habe mein Problem recht gut erklärt
Danke schonmal für eine Antwort
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
21.06.2004, 16:50 Uhr
RHBaum



naja, fuer deine Anforderung wird es wohl etwas schwieriger ....
mit timer wirst ned weit kommen, also wirst wohl Threads verwenden muessen. Schau am besten unter CreateThread , WaitforSingeObject, WaitForMultiObject ... nach ....

ist nicht trivial ....

Ciao ...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
22.06.2004, 09:48 Uhr
Groovejuice



Hmm

d.h ich Soll Senden und Empfangen zusammen in einen Thread packen ?

Gäbe es auch noch andere möglichkeiten wie z.B


C++:
While ("Keine Nachricht Empfangen")
{
  "Behandle aufgetretene Windowsnachrichten"
}



oder hat jemand ein paar Infos wie so eine Netzwerkkommunikation aussieht ?
:

Groove
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
22.06.2004, 11:06 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat:
Groovejuice postete

C++:
While ("Keine Nachricht Empfangen")
{
  "Behandle aufgetretene Windowsnachrichten"
}



Das geht wenn du in deiner Nachrichtenschleife anstatt GetMessage PeekMessage verwendest. Diese funktion wartet nicht auf einer Nachricht sondern sagt direkt ob eine da ist oder nicht.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
22.06.2004, 12:12 Uhr
RHBaum




Zitat:
"Behandle aufgetretene Windowsnachrichten"

Klar geht das ... nur musst dann halt ne alternative nachrichtenschleife selber bauen ....
Wenn aber irgendwas in deiner application dann deine Abarbeitung blockiert ... empfaengst auch nie deine nachrichten ....

Du kannst auch das ON_IDLE ereigniss nehmen, um deine Socket staendig zu nerven ob sie schon was empfangen hat ... :-) Wenn du nicht blockierende Sockets verwenden wills ....

fuer kuerzere sachen ... wo ned so viel Entwicklungszeit investiert werden soll klappts, fuer "ernstere" sachen und sachen die ausbaufaehig sein muessen -> Multithreading / Multiprozessing ....

Ciao ...

Dieser Post wurde am 22.06.2004 um 12:15 Uhr von RHBaum editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
23.06.2004, 12:30 Uhr
Groovejuice



Danke schonmal, ist wohl doch nicht so einfach alles
Ich habe gehofft es hat sich schon jemand mit diesem Problem herumgeschlagen.
Naja wenn man keinen Allgemeinen Algorithmus findet muss man eben jede
Nachricht selber auswerten.

Welche Schleife benutzt Windows eigentlich wenn ein Dialogfeld im leerlauf ist
vielleicht könnte man dort hineinspringen.

Hab mal bei Google sowas ähnliches gefunden.


C++:
while ("Nix Empfangen")
{
Application.PocessData()
}



hat aber leider nicht funktioniert. Ist vieleicht auch gar kein C++ ka.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
23.06.2004, 13:11 Uhr
~RHBaum
Gast



Zitat:
Welche Schleife benutzt Windows eigentlich wenn ein Dialogfeld im leerlauf ist vielleicht könnte man dort hineinspringen.

Windows benutzt keine alternativen!!! Nachrichtenschleifen ... zumindest ned standardmaessig, man kann sich das bauen, tut man meist aber nur in Spezialfaellen. Ist recht kompliziert und weniger untersteutzt.
Und wichtig: der extra Thread fuer die Nachrichtenschleife ist nur fuer das Ausliefern der nachrichten zustaendig, die abarbeitung aller Nachrichten-Handles erfolgt immer im Mainthread, falls nicht expliziet anders definiert.

Die "Fenster" die Nachrichten verarbeiten, nutzen immer nur eine. wenn man andere "Fenster / Controls" subclasst, werden die Nachrichtenschleifen kaskadiert ... die alte nachrichtenschleife empfaengt sie, leitet sie aber an die nachrichtenschleife des untergeordneten controls gleich weiter ....

Es gibt aber einen mechanismus, aus der 16 Bit Area noch, der ON_IDLE sendet, wenn die nachrichtenschleife im leerlauf ist.

wie der mechanismuss genau funzt weiss ich auch ned ... nur funktionieren tuts.

Ich nehm mal an die oberste Nachrichtenschleife erzeugt ON_IDLE, wenn keine Nachrichten vorliegen, Arbeitet ihr Hanlde gegebenfals ab ... wenn, wie bei allen nachrichten, der abbruch-Parameter ned gesetzt ist, gehts an die untergeordneten schleifen weiter ....
wenn die keine nachrichten haben .... dann arbeitens das handle gegebenfals ab, und gebens abhaengig von Abbruch Parameter weiter ....

Nachteil dieser Sache ist .... Klemmt dein ON_IDLE klemmt deine komplette Nachrichtenschleife -> System haengt... also entweder laengere operationen zerstueckeln(zwischendrinn steuerung wieder abgeben), oder ganz vermeiden ....
Genau das ist der Vorteil / die Daseinsberechtigung von multithreading ... du sperrst deine Aktion in nen anderen thread ... und wenn die gemeinsamen objecte ordentlich locken, koennen deine 2 threads schoen nebeneinander arbeiten, ohne gegenseitig ruecksicht zu nehmen (bis auf die gemeinsam benutzen Objecte) ... und du ersparst dir das applicationsgesteuerte hin und herschlalten zwischen den 2 unterschiedlichen Funktionen / Aufgaben ...

Ciao ....
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
29.06.2004, 11:11 Uhr
~Groovejuice
Gast


Danke für die vielen Infos.
Es ging aber mehr um die Frage wie und wo ich diese Routinen in mein Programm einbaue.
Bei meinem Programm gibt es mehrere Buttons und Regler, die alle verschiedene Sachen senden und Empfangen. Wenn ich zb. ein Ereignis schicke "System 2 schick mir eine Liste" so kommt eine Datenliste zurück.
Habe ich die Datenliste empfange will ich sie mit den bereits enthaltenen Daten vergleichen.
Es gibt Auch Kommandos bei denen nur ein OK zurückkommt.
Falls ich wirklich mit Threads arbeite müsste ich für jeden Button, Regler einen eigenen Thread starten da das senden und empfangen darin enthalten sein muss.
Da könnte ich genauso alle empfangenen Ereignisse getrennt behandeln.

Also mein Problem ist eigentlich wie ist eine Kommunikation aufgebaut die per Befehl was sendet und auf die Nachricht reagiert egal welcher Zeitraum dazwischen ist.

Mein Programm reagiert ja schon auf Empfangene Nachrichten, aber wie bekomm ich den Bezug zu dem, was vorher gesendet wurde ?


Mfg
Groove
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ 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: