I have a need for creating a class template and you may help me. [1] Multiple coclasses will be implemented in a single dll. [2] Each coclass will implement the same interfaces but will have different class/clsid/resid. [3] It is necessary to create a class template taking clsid/resid as its template paramemters. [4] Finally, I need to use template classes for CoCreateInstance. Let me elaborate more in detail. Here is a simple interface IA defined. interface IA : IDispatch { [id(1), helpstring("method M1")] HRESULT M1(); }; Below ia a coclass defined with Class(CComX), Clsid(CLSID_ComX), Resid(IDR_COMX). It implements Intid(IA). class ATL_NO_VTABLE CComX : public CComObjectRootEx, , public CComCoClass , public IDispatchImpl { CComX(); ~CComX(); BEGIN_COM_MAP(CComX) COM_INTERFACE_ENTRY(IA) COM_INTERFACE_ENTRY2(IDispatch, IA) END_COM_MAP() DECLARE_REGISTRY_RESOURCEID(IDR_COMX) ... } OBJECT_ENTRY_AUTO(CLSID_ComX, CComX) Next, I need to create second coclass implementing the same interface IA but having different Class(CComY), Clsid(CLSID_ComY), and Resid(IDR_COMY). So, I simply copied the above coclass and replaced 'X' with 'Y'. class ATL_NO_VTABLE CComY : public CComObjectRootEx, , public CComCoClass , public IDispatchImpl { CComY(); ~CComY(); BEGIN_COM_MAP(CComY) COM_INTERFACE_ENTRY(IA) COM_INTERFACE_ENTRY2(IDispatch, IA) END_COM_MAP() DECLARE_REGISTRY_RESOURCEID(IDR_COMY) ... } OBJECT_ENTRY_AUTO(CLSID_ComY, CComY) And I successfully CoCreateInstance'd these two coclasses: HRESULT hr = S_OK; ULONG rc = 0; IA *pXA = NULL; hr = CoCreateInstance(CLSID_ComX, NULL, CLSCTX_ALL, IID_IA, (void **)&pXA); rc = pXA->Release(); IA *pYA = NULL; hr = CoCreateInstance(CLSID_ComY, NULL, CLSCTX_ALL, IID_IA, (void **)&pYA); rc = pYA->Release(); So far so good! The problem is that I need to create many coclasses now and in the future. I don't want to copy/paste for all of them because it is quite hard to maintain the source code for all the copy/paste'd coclasses. It is quite error-prone. So, I definitely would like to create a class template. Below, I created a class template and it compiled ok. template class ATL_NO_VTABLE CCom

Can you clearly explain why the code below triggers the timer twice from time to time, say once in 5-10 executions? MSDN does not explain this weird phenomenon at all.

#if !defined(BTF)
#define BTF(b) (b ? _T('T') : _T('F'))
#endif

#if !defined(ERR)
#define ERR(b, d) (b ? 0 : d)
#endif

BOOL CWTApp::InitInstance()
{
CWinApp::InitInstance();

HANDLE hTimer = CreateWaitableTimer( NULL, FALSE, NULL );

BOOL bRet;
DWORD dwErr;

#define WAITABLETIMER_DUETIME_INITIALLY (0)
#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 200)
#define SLEEP_BEFORE_CWT Sleep(50)

LARGE_INTEGER DueTime;
DueTime.QuadPart = WAITABLETIMER_DUETIME_INITIALLY;

bRet = SetWaitableTimer(hTimer, &DueTime, WAITABLETIMER_PERIOD, NULL, NULL, FALSE);
ATLTRACE(_T("SetWaitableTimer_1(hTimer)=%c/%d\n"), BTF(bRet), ERR(bRet, GetLastError()));

dwErr = WaitForSingleObject(hTimer, INFINITE);
ATLTRACE(_T("Timer(1) was signaled. dwErr=%d\n"), dwErr);

SLEEP_BEFORE_CWT;
bRet = CancelWaitableTimer(hTimer);
ATLTRACE(_T("CancelWaitableTimer(hTimer)=%c\n"), BTF(bRet), ERR(bRet, GetLastError()));

dwErr = WaitForSingleObject(hTimer, INFINITE);
ATLTRACE(_T("Timer(2) was signaled. dwErr=%d\n"), dwErr);

bRet = CloseHandle(hTimer);

return FALSE;
}

David, First of all thx for your kind response. But, I think you have read the code a bit wrong way withing the limit of my knowledge.

Randor wrote:

Your due time is set to the minimum 0xA value (one NT quantum).

This is wrong because I set the initial due time and period as follows at line 15-16

#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 1)
#define WAITABLETIMER_DUETIME_INITIALLY (0)

It is the period that set to 0xA, not the initial due time. The initial due time and period is intentionally set to 0 and 0xA to fire the timer 'immediately first time and ,after then, in the period of every 0xA milliseconds'. Because of 'immediate due time', the timer gets signaled 'immediately' literally, and therefore 'case WAIT_OBJECT_0 + 1:' statement is the first statement executed without any delay. Then socket Connect fails with WSAEWOULDBLOCK error and finally CWT call returns TRUE in sequence. So, the overall code flow is like this:

pWTDlg->m_hTimerRC = CreateWaitableTimer(NULL, FALSE, NULL); // automatic reset timer
bRet = SetWaitableTimer(pWTDlg->m_hTimerRC, 0, 0xA, NULL, NULL, NULL); // immediate, periodic(10ms) timer // TRUE
pWTDlg->m_bCreated = sock.Create(); // TRUE
pWTDlg->m_bConnected = sock.Connect(...); // FALSE with WSAEWOULDBLOCK
bRet = CancelWaitableTimer(pWTDlg->m_hTimerRC); // TRUE

Since the last CancelWaitableTimer returns TRUE, it should stop the timer right away, but the timer gets signaled just one more time. That's the issue! Questions here are - Why is the timer not stopped even after CWT returns TRUE? - Why is the timer always signaled just one more time, not two or three and so on even if I admit the timer can be signaled more times after CWT returns TRUE(of course, I don't admit this, but just for the discussion of this issue, though)? - What's the use of CWT if it is not guaranteed to stop the timer immediately? I'd rather set INFINITE due time and/or INFINITE period for SWT instead of using CWT. I hope I miss something but unfortunately I don't know what are they. Please be very specific and detail explaining what's going on about this issue. regards

> Orjan Westin wrote: > First of all, what do you mean when you say "fails to stop the timer"? > Does CancelWaitableTimer return an error, or does the execution stop at CSocket::Connect? > Details, please. CancelWaitableTimer(CWT) returns TRUE, but fails to stop the timer activated by SetWaitableTimer(SWT). You can download the complete source code from ftp://ftp1.investware.net:1250/Temp/WT3.zip Compiling and running the sample should NEVER raise an ASSERT if CWT works correctly, that is, CWT returning TRUE MUST stop the timer activated by the last SWT. WTDlg.cpp lines 14-17 show some #define statements. [1] First simple test case in which no socket is used and CWT returning TRUE works as expected and succeeds in stoping the timer

#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 1)
#define WAITABLETIMER_DUETIME_INITIALLY (0)

//#define TEST_WITH_SOCKET

[2] Second abnormal test case in which socket is used and CWT returns TRUE, but fails to stop the timer, and therefore ASSERT is triggered.

#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 1)
#define WAITABLETIMER_DUETIME_INITIALLY (0)

#define TEST_WITH_SOCKET

[3] You can test a variety of cases by modifying the first two #define statements. The most significant factor is the value of 'WAITABLETIMER_PERIDO'. When it is - USER_TIMER_MINIMUM * 1, ASSERT is triggered 100%. - ~ USER_TIMER_MINIMUM * 50, ASSERT is triggered 100% as far as I tested. - USER_TIMER_MINIMUM * 75, ASSERT is triggered 1~2 times out of 5 executions. - USER_TIMER_MINIMUM * 100, ASSERT is triggered 1~2 times out of 10 executions. The less significant but still affecting the result is the value of 'WAITABLETIMER_DUETIME_INITIALLY'. When it is -1, much lower possibility of ASSERT. Now, I believe you have all that you can play around. In conclusion, all I can say is that CWT returning TRUE does not stop the timer immediately, but after the timer is signaled one more time for the following sequences: - SetWaitableTimer is called with Duration 0 and period USER_TIMER_MINIMUM - CSocket::Connect or CAsyncSocket::Connect is called - CancelWaitableTimer is called If you find out why CWT returning TRUE fails to stop the timer, please let me know. thx

In normal situations, the following code stops timer as expected: CreateWaitableTimer... SetWaitabltTimer... // with duration 0 and period USER_TIMER_MINIMUM CancelWaitableTimer... Here, I mean 'normal' as 'not using socket calls'. However, when the two conditions are met, CancelWaitableTimer does not stop timer. I've tried to find out why, in vain. The two conditions are: - CSocket::Connect or CAsyncSocket::Connect was called - the last SetWaitableTimer was called with Duration 0 and period USER_TIMER_MINUMUM Actually USER_TIMER_MINUMUM is only to repeat the issue everytime in 100%. If period is long enough, this issue happens irregularly. That is, the following code fails to stop the timer. CreateWaitableTimer... SetWaitabltTimer... // with duration 0 and period USER_TIMER_MINIMUM CSocket::Connect... // use Connect from CSocket or CAsyncSocket CancelWaitableTimer... Since it is too hard to post a complete source code here, I would email the zipped project file if you send me an email to 'ehaerim at gmail dot com'. thx HaeRim Lee

Hi Clawton I have the same issue. It seems the same happens in VC2010 too. First I tried to find out what's wrong in my code, but a few days trial failed and I came here after searching internet. Now I see it's not my code problem but the compiler. Have you found out how to make the debugger not step into the 'return 1'? All the replies below do not clearly commented why it happens and how to overcome it. If you summarize your answers that'd be great. thx HaeRim