Anyway to have a CWnd use HWND_MESSAGE ?
An ordinary window can be converted to a message only window by specifying HWND_MESSAGE as its parent window. It should be possible to use SetParent change the CWnd to a message only window after it is created using:
If you experience problems with this approach, please get back to me.
I've modified FromHandle, and it now accepts psuedo HWNDs (such as HWND_MESSAGE) as well as real windows. You can now create a message only window like this:
// The frame is now created.
// Place any additional startup code here.
// m_MessageWindow is a member variable which inherits from CWnd
You can use Tortoise SVN to download the latest code if you wish.
David, have you checked out the new stl, as implimented by dinkumware and ms vc++, im using vc2010, and after reading an article by kenn kerr about how the new stl containers when used with win api handles and the standard stl container classes have to be wrapped in a move awair container because the stl generially uses move semantics on their classes, im asking this due to he fact a simple 1 widndow application i noticed with NO added code to it , apon resizing it several times grew from consuming 21k to well over 200 megs of memmory over a 15 minute span. I ran it through intel inspector 11 xe and it reported no memmory leaks, but i was watching the apps ram consumption grow.
Yes, the new C++ standard (C++11) introduces some enhancements to the STL. The new changes are quite useful, but it would be a mistake to think that the current STL is somehow flawed and causes memory leaks. Indeed the opposite is true. Using the STL is your best defense against memory leaks. Generally speaking, it is wise to replace dynamically allocated arrays with vectors for example.
The article you refer to highlights the limitations of "auto_ptr", and points out how this particular smart pointer can be misused. The new standard replaces "auto_ptr" with "unique_ptr". Unless your code happens to use "auto_ptr" though, the points mentioned in the article don't apply to your code. We should look elsewhere for the memory leaks.
My hunch is that your memory leaks are actually GDI resource leaks. GDI objects like pens, bitmaps, brushes etc. need to be deleted when they are created, otherwise the will continue to consume memory. Resizing your window causes the background to be erased and the window to be redrawn. This can expose any GDI leaks in your redrawing code.
You can use GDIView to detect GDI resource leaks. It is available for download at: http://www.nirsoft.net/utils/gdi_handles.html
To use GDIView, run it and then run your application and observe the GDI resources it uses. If the number of GDI resources used continue to increase as your application runs (particularly during window resizing) you have a GDI resource leak.