I have not observed similar behavior so I'm afraid I can't help with that. Also please note that the number 42 as second parameter to SetTimer in my example was chosen randomly. Probably, it would be more correct in your context to use the value 0.

This is not MFC as such. SetTimer and KillTimer Windows system functions documented by Microsoft. http://msdn.microsoft.com/library/default.aspx[^] There are many good books and online resources on the subject of C++ programming, Windows system programming and MFC. I suggest you try searching the net for recommendations and book reviews.

You just call ::KillTimer(0, timerId); where timerId is the timer id value you got back from ::SetTimer.

I wrote that example for VS 2008, looks like the callback signature has changed a little since VS6. Try to change it to

void __stdcall myOnTimer(HWND hwnd, unsigned int uMsg, unsigned int idEvent, DWORD tickCount)
{
// ...
}

as the error message suggests. If you have an MSDN library with your VS then you should be able to find the correct callback function signature there. Maybe even an example.

Create a console app and put this code in to see how it works, then you can adapt "myOnTimer" and the call to ::SetTimer to your code.

#include <windows.h>
#include <iostream>

void CALLBACK myOnTimer(HWND hwnd, UINT uMsg, UINT_PTR idEvent, DWORD tickCount)
{
std::cout << "Timer. id = " << idEvent << ", tick = " << tickCount << std::endl;
}

int main(int argc, char * argv[])
{
MSG msg;

UINT_PTR timerId = ::SetTimer(0, 42, 1000, myOnTimer);

std::cout << "Timer set, id = " << timerId << std::endl;

// This is done by MFC in your application but needed for the example.
while(GetMessage(&msg, 0, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}

I assume you talk about MFC and CWnd::OnTimer()? If so, what you describe is how I would expect it to work. That function and CWnd::SetTimer is a thin layer on the Win API ::SetTimer function and WM_TIMER message, where ::SetTimer is called with CWnd::m_hWnd as first arg. If you want the timer to continue after the window is destroyed, why don't you just call ::SetTimer directly with a NULL hWnd and a TIMERPROC? That way your timer will run as long as the thread runs or until you destroy it with a call to ::KilllTimer.

1. Oh absolutely, 2. you were right, though.

1. Yes that could be the intention, but the compiler would look there in any case, wouldn't it? 2. So then we know it took me more than 36 minutes to type in that comment. No wonder I'm not a regular...

Maybe it's a copy/paste bug but that command line doesn't look right to me. 1. The second include is given with option "-I.", that dot doesn't belong there. 2. The rest of the include paths are given without -I arg so the compiler probably won't know what to do with those.

It could be that m_abc->GetProperty returns something other than a bool, so you should also check comVar.vt to see that you really have a boolean.

From the code example I take it that you create the Save2CWGCoilRep thread from the UI thread, i.e. from a menu or button handler function. My guess then is that you have a deadlock: 1. The background thread sends messages to the UI thread. Maybe it tries to display a message box, but it could be anything really. 2. The UI thread is suspended in WaitForSingleObject and can't process the message. It's risky to suspend the UI thread as you don't know when or why messages are posted to it. I would instead protect the critical parts of Save2CWGCoilRep with a critical section and take away the WaitForSingleObject call in the UI thread.

The way you describe it, that string sounds like an object property - the last error message - so it's better and simpler to let it be a member of your class and add an accessor function for it...

class MyClass
{
public:
bool execute()
{
try
{
// ...
throw exception("Testing testing");
return true;
}
catch(exception& e)
{
m_lastError = e.what();
return false;
}
}
CString& lastError()
{
return m_lastError;
}
private:
CString m_lastError;
};

void tryIt()
{
MyClass c;
if( c.execute() )
cout << "All well" << endl;
else
cout << "MyClass.execute failed: " << c.lastError().GetString() << endl;
}

This is safer because you know the CString goes out of scope at the same time your class does, and you still have a CString reference available to use from the rest of your code exactly as before.