Re: SetTimer() & callback handler
Question up front: are you using MFC? In that case, the CWnd class has
SetTimer()/KillTimer() functions that cause a WM_TIMER to be sent which you
can then handle accordingly.
kevin_waite wrote:
My main class is MomPC
[...]
I have a static non-class CALLBACK hander called: btn_timer()
btn_timer() is defined identically to TIMERPROC
I can use SetTimer() successfully with the static btn_timer()
as the 4th parm/CALLBACK to SetTimer().
However, when the handler runs (timer expired) btn_timer()
runs but does not have access to my main class instance
of MomPC -- booooooo.
Typically, APIs that use callbacks have one additional field (typically a
void pointer) which is just passed through to the callback, so that the
user can attach any context information it needs.
In the case of win32's SetTimer(), that is the 'nIDEvent' field. This is
declared as an integer but it is guaranteed that it can also hold a
pointer. So, just write your call like this:
SetTimer(
this->window_handle,
reinterpret_cast<UINT_PTR>(this),
timespan,
&timer_callback);
void CALLBACK timer_callback(
HWND window_handle,
UINT message,
UINT_PTR event,
DWORD time)
{
MomPC* it = reinterpret_cast<MomPC*>(event);
...
}
Alternatively, you can simply use the HWND to send a message or similar
things.
If I make btn_timer() as a method with MomPC -- then I do
not know how to cast &MomPC::btn_timer() into (TIMERPROC)
successfully -- this may be impossible -- I just do not know.
Casting is a bad idea usually. In this case, it doesn't work since a
function is not a memberfunction! Read the C++ FAQ.
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932