Hintergrundaktivität-Cursor bei WaitForSingleObject

Hi!

Unter Windows 7 wechselt der Cursor für 2-5 Sekunden nach "Hintergrundaktivität", wenn man ein bestimmtes Programm ausführt, egal wo man ihn hinbewegt.

Warum ist das so? Das ist das gesamte Programm:

#include <Windows.h>

int __stdcall WinMain(HINSTANCE, HINSTANCE, char*, int)
{
	STARTUPINFO startupInfo = { sizeof(STARTUPINFO) };
	PROCESS_INFORMATION pi1, pi2;

	CreateProcess("C:\\TOOLS\\Misc\\XnView\\xnview.exe", 0, 0, 0, false, 0, 0, "C:\\TOOLS\\Misc\\XnView\\", &startupInfo, &pi1);

	CreateProcess("C:\\TOOLS\\Misc\\HotkeyP\\HotkeyP.exe", 0, 0, 0, false, 0, 0, "C:\\TOOLS\\Misc\\HotkeyP\\", &startupInfo, &pi2);

    // Ab hier ändert sich der Cursor für 2-3 Sekunden
	WaitForSingleObject(pi1.hProcess, INFINITE);

    // Mit dieser Zeile sind es sogar 5 Sekunden
	PostMessage(FindWindow(0, "HotkeyP"), WM_QUIT, 0, 0);
}

Komisch ist ja auch, dass das Programm eigentlich bei WaitForSingleObject hängt, während sich der Cursor ändert, der nachfolgende Aufruf PostMessage() aber trotzdem einen Einfluss auf die Dauer der Cursoränderung hat...

hustbaer

Unter Windows 7 wechselt der Cursor für 2-5 Sekunden nach "Hintergrundaktivität", wenn man ein bestimmtes Programm ausführt, egal wo man ihn hinbewegt.

Vermutung: weil Windows bei Subsystem "WINDOWS" Programmen (=alles was keine Konsole aufmacht) davon ausgeht dass diese bald mal ein Fenster erzeugen.
Dein Programm tut das nicht, Windows wartet aber darauf, also schaltet es einfach mal auf den "Hintergrundaktivität" Cursor um, damit der User weiss "da läuft grad was" -- und das Programm nicht gleich noch 10x anklickt.

Komisch ist ja auch, dass das Programm eigentlich bei WaitForSingleObject hängt, während sich der Cursor ändert, der nachfolgende Aufruf PostMessage() aber trotzdem einen Einfluss auf die Dauer der Cursoränderung hat...

Vermutung: das WaitForSingleObject blockiert nur 2-3 Sekunden, und die restlichen 2-3 Sekunden um auf 5 zu kommen werden vom sich beendenden "HotkeyP.exe" verursacht.

Versuch mal WM_NULL statt WM_QUIT zu posten. Wenn's dann immer noch 5 Sekunden sind vs. 2-3 ohne WM_NULL Posten dann ist meine Vermutung falsch. (Wenn's dann 2-3 Sekunden trotz WM_NULL Posten sind muss sie nicht stimmen, aber ein bestandener Test ist schonmal besser als gar nix :D)

Gute Vermutung. Es reicht sogar ne message pump (der eigentliche Code muss dann halt in nen extra Thread).

Punkt 2 bleibt ein Rätsel, WM_NULL brachte keine Veränderung. Und WaitForSingleObject blockiert INFINITE, XnView schließe ich während der 5 Sekunden nicht. Der Code danach wird definitiv nicht ausgeführt (das Programm beendet nicht).
Vielleicht erkennt das System ja, dass nach dem Wait..() noch Code kommt, und wartet paar Sekunden länger
Statt PostMessage geht auch FindWindow(0, 0); oder MessageBox(0, 0, 0, 0);, ein Beep(1000, 1000); hingegen verlängert die Zeit nicht.