How to use SetTimer replace Sleep()? - c++

Question

I have a application that needs do something step by step, serially, like this:
...
func1();
Sleep(2000);
func2();
Sleep(3000);
func3();
...
As we know, calling Sleep() will cause the user interface to "freeze", so for example there is no response when trying to move the application window.
So, I tried using SetTimer() instead, as it seems that it would not cause the UI to freeze, but my question is how can I implement the same "waiting" function as Sleep() when using SetTimer()?
...
func1();
SetTimer(hwnd, ID_Timer2s,2000, Timerfunc2s);// how to make sure 2seconds waiting happen between func1 and func2?
func2();
SetTimer(hwnd, ID_Timer3s,3000, Timerfunc3s);
func3();
...
// my intention is kill the timer once timeout, then go back next func2(), how?
VOID CALLBACK Timerfunc2s(
HWND hwnd,
UINT message,
UINT idTimer,
DWORD dwTime)
{
KillTimer(hwnd, ID_Timer2s);
}
VOID CALLBACK Timerfunc3s(
HWND hwnd,
UINT message,
UINT idTimer,
DWORD dwTime)
{
KillTimer(hwnd, ID_Timer3s);
}
Thanks for any suggestions.

Answer 1

You want to run func2() only after ID_Timer2s expires, so run it when ID_Timer2s expires. Don't run it immediately.
...
func1();
SetTimer(hwnd, ID_Timer2s,2000, Timerfunc2s);
...
VOID CALLBACK Timerfunc2s(
HWND hwnd,
UINT message,
UINT idTimer,
DWORD dwTime)
{
KillTimer(hwnd, ID_Timer2s);
func2();
SetTimer(hwnd, ID_Timer3s,3000, Timerfunc3s);
}
VOID CALLBACK Timerfunc3s(
HWND hwnd,
UINT message,
UINT idTimer,
DWORD dwTime)
{
KillTimer(hwnd, ID_Timer3s);
func3();
}

Answer 2

As pointed out in the comments, this is not usually an appropriate design for a GUI application.
However, it can be appropriate for some very simple applications, e.g., those that perform a task that requires no user interaction, with a GUI that does nothing but provide feedback as to the progress of the task.
In such cases, and assuming that the code is not being called in the context of a window procedure, something like this should work:
...
func1();
MySleep(hwnd, 2000);
func2();
MySleep(hwnd, 3000);
func3();
...
BOOL MySleepTimerFlag;
void MySleep(HWND hwnd, DWORD timeout)
{
MySleepTimerFlag = FALSE;
SetTimer(hwnd, ID_MySleepTimer, timeout, MySleepTimerFunc);
while (MySleepTimerFlag == FALSE)
{
if (!GetMessage(&Msg, NULL, 0, 0)) fail();
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
}
VOID CALLBACK MySleepTimerFunc(
HWND hwnd,
UINT message,
UINT idTimer,
DWORD dwTime)
{
MySleepTimerFlag = TRUE;
KillTimer(hwnd, ID_MySleepTimer);
}
Note that this code was written off the cuff; I haven't attempted to compile it, never mind test it. But it should at least give you the idea.
Also, note that you can eliminate the global if it upsets you - attach a pointer as a window property or suchlike - but again, globals aren't really all that bad when used in very simple applications. :-)
Finally, the proviso that the call to MySleep() must not be in the context of a window procedure is important. That means that the first part of the code above must not, for example, be triggered by selecting a menu item. If it is, then you must use the approach outlined in Raymond's answer instead, or create a new thread as David suggested.
... also, as Raymond pointed out, you have to be careful that the GUI doesn't have any modal elements such as menus or dialog boxes, or at least that they are disabled while this code is running.

Answer 3

There are (at least) 3 options to do what you want. The first, using timers, Raymond Chen covered. The second, using a customized wait function, Harry Johnston covered. The third option is to create a thread, and do the work using that thread.
For example:
DWORD WINAPI ThreadProc(LPVOID lpThreadParameter)
{
func1();
Sleep(2000);
func2();
Sleep(3000);
func3();
...
return 0;
}
...
DWORD threadId = 0;
HANDLE hThread = CreateThread(NULL, 255, &ThreadProc, NULL, 0, &threadId);
The trouble comes when you need to interact with the UI. You can't directly do things to the UI from the alternate thread, but one technique you can use is to post messages to your UI and/or use shared state variables to affect the behavior of your UI thread.
Of course, it also should go without saying that as soon as you introduce threading, you also introduce the potential for hard to diagnose bugs, like race conditions and deadlocks. If func1, func2 or funcN modify global state you will need to synchronize access, either through critical sections, or some other synchronization method.