CWnd::SetTimer, CWnd::KillTimer

Darius Thabit -- darius@world.std.com
Monday, April 08, 1996


VC++ 1.52, Win 3.1

   I'm getting a failure code from CWnd::KillTimer when I pass back the 
value returned by CWnd::SetTimer.  SetTimer is called in an OnInitDialog, 
and KillTimer in the destructor for the dialog.  Any ideas?  I've verified 
in the debugger that the value doesn't change in between.

   Incidentally, the docs for CWnd::KillTimer say that the value expected in 
nIDEvent should be the value returned by the earlier call to CWnd::SetTimer. 
But the SDK docs say that if the hwnd parameter to ::SetTimer was not null, 
the value passed to ::KillTimer should be the original value _passed_ to 
::SetTimer, i.e. the requested timer ID (in that case the ::SetTimer return 
code is just a status indicator).  It seems from afxwin2.inl that 
CWnd::SetTimer (and CWnd::KillTimer) are passing valid window handles 
(CWnd::m_hWnd) to the SDK functions, so shouldn't the value passed to 
CWnd::KillTimer be instead the requested ID passed to CWnd::SetTimer (and 
_not_ its return value)?  (_Boy_ this is wordy.)

   Now in my case I get back the same value from SetTimer that I pass in 
(namely 1), so the above discrepancy doesn't explain my problem :(

---

Martin J. Mahoney -- mjm@mindspring.com
Wednesday, April 10, 1996

[Moderator's note: There were 10 responses.  8 were basically the
same as this first one.  A couple were way off.]

Darius Thabit wrote:
> 
> VC++ 1.52, Win 3.1
> 
>    I'm getting a failure code from CWnd::KillTimer when I pass back the
> value returned by CWnd::SetTimer.  SetTimer is called in an OnInitDialog,
> and KillTimer in the destructor for the dialog.  Any ideas?  I've verified
> in the debugger that the value doesn't change in between.
> ...

I don't know if this is your problem or not but OnInitdialog is called after
the Windows window has been created but before it is displayed. The destructor
is called after the Windows window has been destroyed. If you move your 
KillTimer into your EndDialog routine, which is called before the Windows 
window is destroyed that might solve your problem.

Martin J. Mahoney

---

| Вернуться в корень Архива |