Using Timers in DLLs....

[Eras3r]

When my DLL is attached, I want to set a Timer.... Since there is no window handle, I'm using TimerProc and not processing WM_TIMER messages. Only problem is... MSDN states that.... "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER."

How can I dispatch messages in a DLL?! .... There must be some other way...

[Eras3r]

I'm thinking the only way I can do this is by creating a window and using that to process the WM_TIMER message...

[Eras3r]

Ok, nevermind.... It seems to be working fine without creating a window and specifying the window handle as NULL. Dunno why the MSDN said what it said.... since it works without using DispatchMessage API....

[Zaei]

You only have to DispatchMessage() if you specify a window handle, but dont process WM_TIMER messages.

Z.

[parksie]

I usually use the timers as a callback (i.e. it just calls one of your functions directly, without the overhead of a window procedure).

[Eras3r]

Ya park, thats what I've been doing since forever. And thats what I'm doing in my DLL. But it was just strange how the MSDN stated that you must dispatch messages whether you use a callback or not.. Which I found odd. And apparently that statement is incorrect.. Or typed wrong. ;)

[parksie]

Or maybe it's just filling up your process's message queue ;)

Strange, I never seemed to have any problems by not handling WM_TIMER...although the dubious stability of my computer could have either been that or Windows 98...

I stopped using SetTimer when I noticed it was decidedly inaccurate...timeSetEvent is a lot better, and doesn't do things to the message queue.

[Eras3r]

Hmmm, I think I might start using timeSetEvent now... Thanks :)