Search

CWnd::PreCreateWindow change causing problems by Kyle Schmidt

Closed
as Fixed Help for as Fixed

3
0
Sign in
 to vote
Type: Bug
ID: 632178
Opened: 12/17/2010 6:53:56 AM
Access Restriction: Public
1
Workaround(s)
3
User(s) can reproduce this bug
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) && (cs.style & WS_CHILD))
    {
        cs.hMenu = (HMENU)(UINT_PTR)this;
    }

This code is not in VS2008.
Details (expand)

Visual Studio/Silverlight/Tooling version

Visual Studio 2010

What category (if any) best represents this feedback?

Compatibility

Steps to reproduce

Call CreateEx on a CWnd with the style WS_CHILD.

Product Language

English

Operating System

Windows 7

Operating System Language

English

Actual results

CreateEx fails which later causes other issues in my application.

Expected results

CreateEx should create a window.
File Attachments
0 attachments
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(http://support.microsoft.com)
Sign in to post a workaround.
Posted by RD Holland on 2/16/2011 at 12:10 PM
After passing in zero as the ID to Create(Ex), call SetDlgCtrlID( 0 );
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement