How to SetTimer in a thread without window?
NowCan
SetTimer(NULL,NULL,1000,TimerProc),is it right?
William DePalo [MVP]
news:eadhzCgfBHA.1872@tkmsftngp04...
> How to invoke function SetTimer in a thread?
>
> SetTimer(NULL,NULL,1000,TimerProc),is it right?
Don't. <g> Use timeSetEvent() instead. If the callback must run in the
context of the original thread you can queue it an APC - see QueueUserAPC().
Seriously, if you want to use SetTimer() you will have to spin a message
loop.
Regards,
Will
Daniel Lohmann
Of course you have to spin a message loop.
However this does not mean that you need a *window*. Just setup a
simple message loop and it works fine.
Another option may be waitable timers (CreateWaitableTimer())
Daniel
Roger Pfister
> How to invoke function SetTimer in a thread?
>
> SetTimer(NULL,NULL,1000,TimerProc),is it right?
>
Timers do WORK in threads honest
This is IMO a gross doc err in all the windows/msdn docs
ADD a messaage map entry (to your thread)
ON_THREAD_MESSAGE( WM_TIMER, OnThreadTimer ) // Thread Timer Special
and have in the threads class def
int m_nOneTimerId;
void CMyThread::OnThreadTimer( WPARAM nIDEvent, LPARAM)
{
// std timer processing except use var defined as above
if (nIDEvent == m_nOneTimerId)
{
// usual action
// eg KillTimer( m_nOneTimerId); m_nOneTimerId = 0;
}
}
SET THE TIMER as follow ---------- important ------------
m_nOneTimerId = SetTimer( 0, 0, 1000 /* ms */, 0);
YES SetTimer() is defined a for a thread they just havent documented it.
--
Roger
William DePalo [MVP]
news:VA.0000006...@rpsd.net...
> YES SetTimer() is defined a for a thread they just havent documented it.
They have. That's because _everything_ that executes executes in the context
of a thread. It doesn't much matter whether the thread was created for you
when your program was launched or whether you explicitly created a new one.
The O.P. mentioned he had a problem in a thread without a window. Many
windowless threads don't spin message loops. If a thread doesn't spin a
message loop SetTimer() is useless.
Regards,
Will
Roger Pfister
> YES SetTimer() is defined a for a thread they just havent documented it.
>> They have. That's because _everything_ that executes executes in the
context
>> of a thread. It doesn't much matter whether the thread was created for you
>> when your program was launched or whether you explicitly created a new one.
Umm clearly what you consider "documentation" and what I consider
"documentaiton" do not overlap. I refer you to MSDN LIB and the def of
SetTimer
hWnd
[in] Handle to the window to be associated with the timer.
This window must be owned by the calling thread. If this
parameter is NULL, no window is associated with the timer
and the nIDEvent parameter is ignored.
YOU may know enough to know that what the above realy means is
THIS WORKS WITHOUT A WINDOW
but it did not read that way to me and it (I contend) does not
read that way to _any_ other new punter
Historialy of course the windows came first and then the thread
hence the lack of clean support for thread timers in MFC (sorry
this is the Kernel NG)
Hence I re-state my view that this is the WORST doc err in the
whole of MSDN
--
Roger
William DePalo [MVP]
> hWnd
> [in] Handle to the window to be associated with the timer.
> This window must be owned by the calling thread. If this
> parameter is NULL, no window is associated with the timer
> and the nIDEvent parameter is ignored.
>
>
> YOU may know enough to know that what the above realy means is
>
> THIS WORKS WITHOUT A WINDOW
>
> but it did not read that way to me and it (I contend) does not
> read that way to _any_ other new punter
No window has a NULL handle. QED.
> Historialy of course the windows came first and then the thread
> hence the lack of clean support for thread timers in MFC (sorry
> this is the Kernel NG)
I responded here to dispel misconceptions I hear all the time. (Of course I
can't be sure if you share them) ...
... but there are those who think that if they don't call CreateThread(),
beginthread(), beginthreadex(), or AfxBeginThread() that they are not
dealing with threads. They are wrong. Threads are all there is to execute in
applications. Period.
Worse there are MFC programmers who think that there is a difference between
worker threads and UI threads at the level of the API. There is none. MFC
has no special standing in Win32, none, nada, zippo. The scheduler schedules
threads. A UI thread simply needs to pump messages posted to its queue for
any windows it owns. The message queue for _any_ thread is created on the
fly on an as needed basis. Worker or UI thread is a distinction made by MFC,
not Win32.
Back to SetTimer() ...
When a timer "comes due" that fact is recorded with other event queue
information. Later when a thread calls GetMessage() or PeekMessage(), and
when Windows determines there is nothing more pressing than the timer
message in the thread's queue (realize that these timers are low priority
events to Windows), Windows constructs a timer message or calls a callback
function.
In short, pumping messages (something MFC hides a bit) is central to
processing this kind of timer. Whether a window is involved or not is not
relevant.
Regards,
Will