IsWindow/DestroyWindow Threading Issue
-
Ack. Just been bitten by an old classic that some people may not be aware of. I have a multi-threaded ATL app, and one of the threads needs to create a hidden window in order to intercept messages from a PDF driver. To keep resources to a minimum, this window is created the first time it is needed, rather than on startup. All seemed to be working OK, except, when the app closes, an assert was being thrown by the following code found in the destructor of the class that created the window:
if (notify_wnd_ != NULL)
notify_wnd_.DestroyWindow()On inspecting the ATL
CWindow::DestroyWindow(in atlwin.h) I came across the following:ATLASSERT(::IsWindow(m_hWnd));
This explains my mistake - the thread that created the window is different to the one used to destroy it, which, according to the MSDN docs, is a no-no - in fact, the
IsWindowandDestroyWindowpages both make specific mention of this. While frameworks such as ATL, MFC, WTL, etc. are incredibly useful, it is always worth knowing what they are doing under the hood, as this example shows. A little knowledge of the Win32 API is still essential IMHO, even with a variety of frameworks available that are designed to hide the details away. I hope someone else finds this useful.
Kicking squealing Gucci little piggy.
-
Ack. Just been bitten by an old classic that some people may not be aware of. I have a multi-threaded ATL app, and one of the threads needs to create a hidden window in order to intercept messages from a PDF driver. To keep resources to a minimum, this window is created the first time it is needed, rather than on startup. All seemed to be working OK, except, when the app closes, an assert was being thrown by the following code found in the destructor of the class that created the window:
if (notify_wnd_ != NULL)
notify_wnd_.DestroyWindow()On inspecting the ATL
CWindow::DestroyWindow(in atlwin.h) I came across the following:ATLASSERT(::IsWindow(m_hWnd));
This explains my mistake - the thread that created the window is different to the one used to destroy it, which, according to the MSDN docs, is a no-no - in fact, the
IsWindowandDestroyWindowpages both make specific mention of this. While frameworks such as ATL, MFC, WTL, etc. are incredibly useful, it is always worth knowing what they are doing under the hood, as this example shows. A little knowledge of the Win32 API is still essential IMHO, even with a variety of frameworks available that are designed to hide the details away. I hope someone else finds this useful.
Kicking squealing Gucci little piggy.
As far as I know its has something to do with Windows 3.1 behavior, which the following Windows inherited. Note that in .NET you have the same issue, if you create a control in one thread, for example label on a form, the label can only be update on the same thread that it was created. In .NET 1.1 it works, but in .NET 2.0 it throws an exception. Frameworks or not, you must know what Windows does. Ami
-
As far as I know its has something to do with Windows 3.1 behavior, which the following Windows inherited. Note that in .NET you have the same issue, if you create a control in one thread, for example label on a form, the label can only be update on the same thread that it was created. In .NET 1.1 it works, but in .NET 2.0 it throws an exception. Frameworks or not, you must know what Windows does. Ami
Ami Bar wrote:
Note that in .NET you have the same issue, if you create a control in one thread, for example label on a form, the label can only be update on the same thread that it was created.
AFAIK, this is a different issue - the subsystem isn't threadsafe, so you could run into problems trying to (say) change window text from two different threads at once. .NET 2.0 disallows it simply because of the problems it can cause...