afxGlobalUtils - C++ - by Juan Foegen

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 615996 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/22/2010 12:13:41 PM
Access Restriction Public


I have a C++ application that I was porting from VS 2008 to VS 2010.  I had a dialog where I added MFCTasksPanes to my dialog.  I am not worried about docking within the dialog, but I wanted the functionality the control provides.  This worked fine in VS 2008 with the feature pack, but with some changes you made to VS2010, I then received an exception in the CDockablePane::HitTest method.  In order to get my dialog to work I ended up subclassing the CMFCTasksPane and overriding HitTest (where I got rid of the afxglobals) and GetDockSiteFrameWnd (where I now return NULL).

The common response is to say the taskspane control can only be used by dockable windows, but there are needs for these controls in dialogs and property pages, not just in main window or a child frame.

But that thing that disturbed me is the whole use afxGlobalUtils.  When you try to subclass the CDockablePane::HitTest you CANNOT because if you are building the DLL version the afxGlobalUtils ends up being undefined when doing the link.  Why can I not get to this?  Why can I not subclass CGlobalUtils and change a method like GetDockingManager?  Since you only want one copy there could be a pointer in CWinAppEx that we could set so this can be overridden.  I am very concerned this class is very intertwined in a lot of classes, but yet we as programmers cannot adjust its behavior.
Sign in to post a comment.
Posted by Juan Foegen on 12/6/2010 at 5:45 AM
So what was "fixed"? That afxGlobalUtils can be used inside of a MFC DLL or that afxGlobalUtils can be subclassed or both?

Thanks for looking at this issue.
Posted by Microsoft on 12/3/2010 at 1:02 PM

Thanks for the report and additional data. This issue has been fixed in MFC for the next major release of Visual Studio.

Pat Brenner
Visual C++ Libraries Development
Posted by Microsoft on 11/5/2010 at 1:59 AM
Thanks for your feedback.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Juan Foegen on 11/2/2010 at 1:20 PM
I was not able to start working on an example until today, but I will attach my example.

You can start up the application and you will see a different menu item with two different dialogs. These dialogs are similar to what I have in my application. Since this is in a dialog not in the main frame, there is no docking going on, but VS2010 in a few places is not happy about that.

The main focus is in MyTasksPane::HitTest. My version of the method is the exact copy of the parent except for the lines I was forced to comment out. Comment those back in and you will see the error. This is my point, as a user of MFC, I may want to change how CGlobalUtils works, especially the GetDockingMananger, but with how that is defined you cannot get to it. That is why I am saying MFC's CBasePane should really use a pointer to a CGlobalUtils member in CWinAppEx, so an override can happen in an extension DLL without issue. Then if the MFC user needed new functionality, he could then subclass CGlobalUtils and set a different instance in the CWinAppEx if additional functionality was needed.

The sample I gave you started with new VC10 projects, so the main frame was subclassed off of CMDIFrameWndEx. Where I initially noticed the problem was in my older program that used CMDIFramWnd. This caused me to get a CGlobalUtils::GetDockingManager of NULL and caused the HITTest ASSERT to fail. This is what caused me to want to override the method in the first place.

The other problem I had was when I closed down my dialog and CBasePane::RemovePaneFromDockManager was called. This also asserted. In my "real" program's task pane I set a flag to know if the pane is used in a dialog and if it is I override HitTest and have GetDockSiteFrameWnd return NULL.

So yes, I was able to work around this in my application, but I can also see how the CGlobalUtils could become a major problem when trying to personalize my own behavior.

Posted by Microsoft on 10/29/2010 at 1:45 AM

Sorry for bothering. Is there any update?

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, we will close this issue.

Thanks you,
Posted by Microsoft on 10/25/2010 at 12:20 AM
Thank you for reporting this issue. In order to research the issue reported, we must first reproduce in our labs. Unfortunately, we are unable to reproduce the issue with the steps you provided.

Could you please provide us with a sample project zip?

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thank you,
Posted by Microsoft on 10/22/2010 at 12:23 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(