Re: Thread and Timer

From:

"David Ching" <dc@remove-this.dcsoft.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 13 Mar 2008 13:02:57 -0700

Message-ID:

<SLfCj.377$qT6.136@nlpi070.nbdc.sbc.com>

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:irsit3lmg7rsp21388mvaf17cj43m13jbo@4ax.com...

To get WM_TIMER messages, yes. This trick is actually pretty common; for
example,
CAsyncSocket creates a dummy window to handle callback notifications,
which are sent as
window messages; SAPI creates a dummy window to handle Text-to-Speech
notifications; and I
knew about the trick years ago. Any generic derived-direct-from-CWnd
class will do
nicely.

Timer callbacks will work without a window, but overall they suck badly,
because there is
no user-specified data object passed in (as I explain to my students, the
callback
function has four parameters, three of which are totally useless and one
of which is never
used anyway, so why do we have four useless parameters? Bad design. You
can't really
make a thread-safe callback without a lot of effort; __declspec(thread)
helps, or direct
use of Thread Local Storage.

I think you misunderstood. AliR was promoting handling the WM_TIMER message
in the CWinThread message map. This means there is no HWND created for it.
And since it is a WM_TIMER message, the handler does have a this pointer, so
state can be preserved (in the CWinThread object).

He was not saying to use the SetTimer() variant which uses a callback
function.

-- David