Application wide periodic tasks with Dialog Based MFC application

Question

In Single Document Interface (SDI) or Multiple Document Interface (MDI) MFC application, I created an application wide timer in the View. The timer will tick as long as the application is running and trigger some periodic actions.

How can I do the same with Dialog Based MFC application?

1. Should I create Thread's Timer (SetTimer with NULL HWND) and pass a callback function to it?
2. Should I create worker threads? My experience with other projects was when I tried to display some feedback GUI from non-GUI/worker threads, I need to roll out my own "delegate"/command pattern and a "delegate invoker"/command invoker. The worker thread will send message (I think using message is safer than direct function call when dealing across thread-boundary, CMIIW) to the UI-thread. and the UI-thread will be the "delegate"/command invoker. Failing to do this and to make sure that the windows/dialogs have the correct parent will result in bizzare behaviors such as the Application suddenly disappears to the background; Window/Dialog that is shown behind the current window/dialog and causing the current window to be unresponsive/unclickable. Probably I was doing something wrong but there were so much problems when dealing with threads.

Are there best practices for this?

Answer 1

A timer works as well in a dialog-based application as an SDI or MDI app. OTOH, timers are (mostly) a leftover from 16-bit Windows. If you want to do things periodically, a worker thread is usually a better way to do it (and yes, Windows Mobile supports multiple threads).

Edit: in a dialog-based application, the main dialog exists for (essentially) the entire life of the application. Unless you really need the timer during the milliseconds between application startup and dialog creation or dialog destruction and application exit, just attach it to the dialog. Otherwise, you can attach it to the main window -- which MFC creates and destroys, even though it's never displayed.

Answer 2

If you use the MFC Wizard to create the Dialog based app, you probably have a hidden view window as well as a dialog window. The view window creates the dialog with DoModal(), which runs the dialog in the same thread, effectively suspending the view window.

While the dialog is open, the view window will not process any events. So, if the view window owns the timer, it will not process the timer events.

The simplest solution is to create the timer in the dialog and let the dialog handle the timer messages.

Answer 3

IMO, use the Timer if it solves the problem. As you've mentioned a Worker Thread interacting with the UI, in MFC, can be more trouble than its worth sometimes.

If the problem is simple enough for a timer to suffice, thats what i'd use (Remember KISS)

SetTimer does not have to be handed a window to work, it can call a callback method.

You can use that in your application - declare in your CWinApp (or anywhere really)

static void CALLBACK OnTimer(HWND, UINT, UINT, DWORD);

Then in the InitInstance call SetTimer(0, [eventid], [time period], OnTimer);

In OnTimer you can get back to the CWinApp instance via AfxGetApp() or theApp since there is only one.