CWnd::PreCreateWindow change causing problems - by Kyle Schmidt

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 632178 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 12/17/2010 6:53:56 AM
Access Restriction Public


CWnd::PreCreateWindow was changed in visual studio to assign the hMenu member of the CREATESTRUCT to "this" if the menu is NULL and the style has WS_CHILD.  Custom controls that use the WS_CHILD style are now failing to create (via CWnd::CreateEx) because the hMenu value is being set to an invalid value during PreCreateWindow. 

The code in question in CWnd::PreCreateWindow is:

	if ((cs.hMenu == NULL) && ( & WS_CHILD))
		cs.hMenu = (HMENU)(UINT_PTR)this;

This code is not in VS2008.
Sign in to post a comment.
Posted by Pat Brenner MSFT on 3/16/2011 at 11:07 AM
Hello all,

This is not a bug. This was a by design change in MFC for VS2010. The change fixes a crash in managed/native interop scenarios.

There is a TRACE statement in CWnd::Create which attempts to alert the developer of the problem. Basically, any dialog control now must have an ID other than zero in order for GetDlgItem to work correctly.

Pat Brenner
Visual C++ Libraries Development
Posted by RD Holland on 2/16/2011 at 12:09 PM
This is so simple to reproduce why reject the issue? Just create a CEdit control (or any child window) in MFC and when calling the CreateEx function, pass in zero as the "nIDorHMenu" argument. Then call GetDlgCtrlID and see what is returned.

Putting the "this" pointer as the window ID causes calls to GetDlgCtrlID (valid whether a real control or not) to return an "unknown" number because the value returned is the value of the "this" pointer. This is causing us problems after we moved to Visual Studio 2010. We are forced to call SetDlgCtrlID(0) AFTER we specified zero in the CreateEx call!

So what is the reason for sneaking a pointer into the window as the ID. You do realize a window handle can be detached and attached to another window? And control IDs are quite important to some users.

So is this a bug or not? And when will it be fixed?
Posted by Microsoft on 12/30/2010 at 6:55 PM
Hi, given that we have not heard back from you, we will go ahead and close this Connect Issue. If you get a chance to review and provide the information requested earlier, you can go ahead and reactivate this issue.(Click “Edit this item” button on the site and change the “Status” to “Active”)
Posted by Microsoft on 12/19/2010 at 8:33 PM
Thanks for reporting this issue. In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Please give us a demo project to demonstrate this issue so that we can conduct further research.

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 5 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 12/19/2010 at 5:43 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(