Mein Thread wird einfach nicht beendet, sobald ich dies reinschreibe:

SendMessage(listHandle, LB_GETCOUNT, 0, 0);

Kann doch nicht sein? Ohne SendMessage schließt der Thread sofort.

// Im thread
	while(!exitMainThread)
	{
		Tick();
	}

exitMainThread setze ich auf true, sobald das Programm geschlossen wird. Trotzdem rennt der thread weiter... Was ist da los?

Wenn ich MessageBox(0, 0, 0, 0) nach SendMessage schreibe, dann tritt das Problem nicht auf...

Oder wenn ich Sleep(1000) nach SendMessage schreibe, tritt das Problem auch nicht auf!

Allerdings wird Tick nicht mehr ausgeführt, hab das schon getestet mit einer Datei in die bei jedem Tick() was geschrieben wird. Schließe ich das Programm, wird nix mehr reingeschrieben, aber die .exe läuft noch immer (Visual Studio: Running...)

Da stimmt doch was nicht... Wiegesagt, liegt nur an LB_GETCOUNT, ohne dem funzts. Hab auch schon probiert, zuerst if(listHandle) zu schreiben, da die ListBox nach Beendigung des Programmes ja zerstört wird, und so LB_GETCOUNT vielleicht blockiert, hat aber auch nicht geholfen!

Danke!
MfG

listHandle

überhaupt nachrichten ab? ansonsten kannst du noch PostMessage() verwenden. dieses postet die message in der messagequeue des fensters und kehrt danach sofort zum aufrufer zurück.

Wenn ich...

if(FindWindowEx(listHandle, 0, 0, 0))
	SendMessage(listHandle, LB_GETCOUNT, 0, 0);

...schreibe, dann wird brav geschlossen. Also liegt es wohl, wie du schon vermutet hast, daran, dass SendMessage() noch aufgerufen wird, obwohl das Hauptfenster (Und somit der MsgProc()?) schon futsch ist...

Mit PostMessage() schließt der Thread nun, aber der aufrufende thread hat nicht die Nachrichtenschleife. Da wollte ich PostThreadMessage() verwenden, aber wie bekomme ich die ID des Hauptthreads, der bei jedem Programm existiert, ohne dass man ihn erstellen muss, und ist das überhaupt der richtige Weg so?

Danke!
MfG

"The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window "

Naja weil mit PostMessage() erhalte ich nicht mehr die Ergebnisse als wie mit SendMessage(). LB_GETCOUNT ist immer 1 und LB_ADDSTRING hat auch keinen Effekt mehr...

Die Nachrichtenschleife des parent windows sieht übrigens so aus:

MSG message = { };
	while(GetMessage(&message, 0, 0, 0))
    {
		if(!IsDialogMessage(MyClass::getInstance().getWindowHandle(), &message))	
		{
			TranslateMessage(&message);
			DispatchMessage(&message);
		}
    }

Nochmal, vielleicht zur Entwirrung:
PostMessage() sende ich von einem zweiten Thread aus, hat aber keinen Effekt auf die ListBox... SendMessage() schon.

Danke!
MfG

Hauptthread:
- Parent window mit MsgProc
- Child window (listHandle)
Bei WM_DESTROY wird exitMainThread auf true gesetzt

Nebenthread:

while(!exitMainThread)
    {
        Tick();
    }

Nachdem man das Programm beendet, werden ja die Fenster abgebaut, und der MsgProc wird dann auch nicht mehr aufgerufen. Aber der Nebenthread macht noch einen Durchgang mit SendMessage(listHandle, ...), wo er dann stecken bleibt, weil wohl das Child schon abgebaut ist bzw. der MsgProc nicht mehr vorhanden ist.

PostMessage hat keinen Effekt, SendNotifyMessage oder SendMessageCallback hab ich auch schon probiert, hat alles keinen Effekt, nur SendMessage tut was, blockiert aber leider...

Danke!
MfG

Grundsätzlich ist es mieses Design, Deinen Hauptthtead beenden zu lassen (Fenster die andre verwenden zu zerstören), ohne die Workerthreads kontrolliert zu terminieren.

Grundsätzlich ist es mieses Design, Deinen Hauptthtead beenden zu lassen (Fenster die andre verwenden zu zerstören), ohne die Workerthreads kontrolliert zu terminieren.

ACK

Danke!
MfG

(TerminateThread ist eine Notfalllösung für den Fall, daß der Thread dir dein Betriebssystem zerhackstückt)

MfG

Aber der Nebenthread sollte dann statt SendMessage() lieber PostMessage() oder SendMessageTimeout() verwenden, um das Hauptprogramm über Neuigkeiten zu informieren, sonst bekommst du einen erstklassischen Deadlock (der Thread wartet darauf, daß das Hauptprogramm seine Nachricht verarbeitet, das Hauptprogramm wartet darauf, daß der Thread sich beendet).

Mit...

SendMessageTimeout(listHandle, LB_ADDSTRING, 32, reinterpret_cast<LPARAM>("blatext"), SMTO_ABORTIFHUNG, 1, 0)

...haut es nun hin. Die Reaktion auf WM_DESTROY sah schon immer so aus:

if(threadHandle)
		WaitForSingleObject(threadHandle, INFINITE);

	CloseHandle(threadHandle);
	PostQuitMessage(0);

Eigentlich sollte hier doch sowieso gewartet werden, bis der Nebenthread fertig ist, und dann erst die Nachrichtenschleife & Fenster zerstört werden?!

Danke!
MfG

Hey!

Mit...

SendMessageTimeout(listHandle, LB_ADDSTRING, 32, reinterpret_cast<LPARAM>("blatext"), SMTO_ABORTIFHUNG, 1, 0)

...haut es nun hin.

Meinst du nicht, daß ein Timeout von einer Millisekunde im aktiven Dienst ein wenig knapp bemessen ist? Wenn du Pech hast, kommt die Nachricht gerade während einer etwas längerfristigen Tätigkeit des Hauptprogramms.

Eigentlich sollte hier doch sowieso gewartet werden, bis der Nebenthread fertig ist, und dann erst die Nachrichtenschleife & Fenster zerstört werden?!

Ja, das war auch korrekt - nur während du dort gewartet hast, blieben die Nachrichten des Thread in der Warteschlange hängen.

SendMessageTimeout(listHandle, LB_GETCOUNT, 0, 0, SMTO_ABORTIFHUNG, 1000, 0);

Gibt immer 1 zurück, SendMessage() hingegen arbeitet korrekt. Warum hat PostMessage() usw. eigentlich keinen Effekt bei mir (Gibt bei LB_GETCOUNT auch immer 1 zurück und LB_ADDSTRING zB. hat gar keinen Effekt) ?

Danke!
MfG

DWORD answer,result;
result = SendMessageTimeout(listHandle,LB_GETCOUNT,0,0,SMTO_ABORTIFHUNG,1000,&answer);
if(result==0)
{
  //Fehler oder Timeout
}
else
{
  //Erfolg:
  TRACE("Count returned: %d\n",answer);
}

(PostMessage() mit LB_ADDSTRING hat ein anderes Problem - der übergebene String ist möglicherweise schon ungültig, bevor das Zielfenster die Nachricht auswertet)

Danke, meine Voreiligkeit

Hätte es gerne irgendwie ohne Timeout gelöst, also falls wem noch was einfällt, bitte!

MfG

Aber was genau hast du eigentlich gegen Timeout? Die Angabe dort bedeutet doch nicht, daß die Funktion immer 1 Sekunde wartet, bevor sie abbricht - das ist die maximale Wartezeit. (und im Normalbetrieb liefert sie genauso zuverlässig eine Antwort wie SendMessage())

Was meinst du mit "kann nicht mit Zeigern umgehen"? Dass ich zB. nicht LB_GETCOUNT verwenden kann? Denn wenn diese Funktionen sofort zurückkehren, und die Nachricht noch nicht verarbeitet wurde, wo soll dann das Ergebnis sein?

MfG

Naja, die Anwendung läuft dann eben nach Beenden noch eine Zeit lang weiter, wenn ich im Nebenthread oft SendMessageTimeout() aufrufe, kommen schon mal 10 Sekunden oder mehr zusammen. Find ich nicht so toll.

Da wäre es auch eine gute Idee, die Bedingung "Timeout wurde ausgelöst" als Abbruchbedingung des Threads zu verwenden - so daß du nur einen einzigen fehlgeschlagenen Aufruf hast (und eine Sekunde Wartezeit sollte akzeptabel sein).

Was meinst du mit "kann nicht mit Zeigern umgehen"? Dass ich zB. nicht LB_GETCOUNT verwenden kann? Denn wenn diese Funktionen sofort zurückkehren, und die Nachricht noch nicht verarbeitet wurde, wo soll dann das Ergebnis sein?

Nein, damit meinte ich eher das Problem, was ich oben mit LB_SETTEXT angesprochen hatte - weil die Funktionen sofort zurückkehren, sind die übergebenen String-Daten womöglich nicht mehr gültig, wenn das Ziel endlich zur Verarbeitung kommt.

(hast du zufällig die MSDN in Reichweite? Wenn ja, empfiehlt sich ein Blick in die Funktionsbeschreibungen - speziell die "Remarks" Sektion ist immer wieder aufschlußreich)

Oder soll ich einfach vor jedem dieser Aufrufe prüfen, ob exitThread nicht schon TRUE ist, und gegebenfalls returnen...?!

MSDN ist mir nicht fremd, ich bin aber einfach davon ausgegangen, dass die *Message*- Funktionen gleich funktionieren, sry.

MfG

Lass SendMessage aus einem Thread in einen anderen einfach bleiben!

Mein Programm soll doch reagieren, während es beschäftigt ist:

- ListBox eines fremden Fensters auslesen
- Daten verarbeiten
- 1 Sekunde Warten (Sleep())
und wieder von vorn...

Es soll nicht 100x in der Sekunde diese Aufgabe tun, sondern sekundenweise (1. wegen Prozessorlast, 2. muss es die Aufgabe gar nicht so oft tun). Während dem Sleep() würde das GUI doch nicht mehr reagieren...

Wenn ich einen weiteren Thread erstelle, und dieser eine Sekunde "schläft", reagiert währenddessen das GUI... deshalb der zweite Thread.

Was gibt es noch für Möglichkeiten?
Danke!
MfG

- ListBox eines fremden Fensters auslesen

MfG

Ich werde wohl einen Windows Timer verwenden, der jede Sekunde die Auslese- und Verarbeitungsaufgabe aufruft, aber da ist noch ein anderes Problem:
Das Programm soll per Winsock fernsteuerbar sein.

Die Probleme, ohne einen zusätzlichen Thread zu erstellen:
- listen() geht schonmal nicht, da es blockiert und somit auch das GUI
- select() geht nicht, weil ich nicht 100% Prozessorauslastung möchte, und Sleep(1) möchte ich nicht einbauen weil sich dann das GUI beim maximieren so langsam aufbaut...

Was soll ich nur tun?
MfG

- listen() geht schonmal nicht, da es blockiert und somit auch das GUI

du meinst accept!