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.

Answer 4

Second attempt: my previous answer was dne in a hurry and was not correct.

Your basic vanilla MFC Dialog app only uses one thread. The main thread starts with a class derived from CWinApp. In the InitInstance() method it launches the dialog using CDialog::DoModal(). This function doesn't return until the dialog is closed.

While the dialog is running, the CWinApp class does not process any messages, so won't see a WM_TIMER.

There are many ways around this.

1. Let the first dialog own the timer and make all other dialogs children of it. This might be OK, depending on your dialog requirements, but it might be too restrictive.

2. Launch the first Dialog as modeless, ie use Create() instead of DoModal(). Create() returns straight away (putting the Dialog into a different thread). You can then create a message loop in the CWinApp class and process timers there. You'll have to use thread timers instead of window timers as the CWinApp class doesn't have a window. (or you could create a hidden window if that is more convenient).

3. You can hack the dialog's mesage loop and make it pass messages to the CWinApp class' message handler. That is quite complex and not for the faint hearted.

4. You can create a dedicated timer thread. You'd probably do that from the CWinApp class before it creates the dialog, but other strategies are possible.

Do any of those schemes sound like they fit your needs? If not, maybe you can explain your needs more fully and we might be able to come up with something appropriate.