CMFCPropertyGridCtrl from Dll and exe assert
-
Hi, I am developing a desktop application composed by the main exe and several modules (dll / plug-ins) . The main modules has a dialog where a CMFCPropertyGridCtrl is used to edit a collection of name/values pair. Also another dll has a wizard that make use of a property sheet where a CMFCPropertygridCtrl edits another collection of name/values pair. The application works as expected if only one of these dialog is executed. No matter what is the sequence, the second time the dialog is opened, the program asserts. I can open the same dialog more times, and it do not asserts, it asserts only when the second kind of dialog is opened. The dialog (both) asserts when the mouse pointer is passed over the CMFCPropertyGridCtrl Control, the stack traces from the TrackToolTip function inside the class. I have tracked the problem to the creation of the tooltip window: in CMFCPropertyGridCtrl::Init() the call to m_IPToolTip.Create(this) fails: BOOL CMFCPropertyGridToolTipCtrl::Create(CWnd* pWndParent) { ASSERT_VALID(pWndParent); m_pWndParent = pWndParent; if (m_strClassName.IsEmpty()) { m_strClassName = ::AfxRegisterWndClass(CS_SAVEBITS, ::LoadCursor(NULL, IDC_ARROW), (HBRUSH)(COLOR_BTNFACE + 1)); } return CreateEx(0, m_strClassName, _T(""), WS_POPUP, 0, 0, 0, 0, pWndParent->GetSafeHwnd(), (HMENU) NULL); } The first time this function executes, the CreateEx return TRUE and all works as expected. The second time, only if from a different module (DLL or EXE), m_strClassName is not empty and CreateEx fails with error code 0x00057f e.g. "Warning: Window creation failed: GetLastError returns 0x0000057F" that is ERROR_CANNOT_FIND_WND_CLASS. I do not use any tooltip, so I could also disable the tooltip feature. (stack trace of the assertion, when the mouse passes over the grid (WM_MOVE) ) mfc90ud.dll!CWnd::GetWindowRect(tagRECT * lpRect=0x0012f06c) Riga 116 + 0x2a byte C++ mfc90ud.dll!CMFCPropertyGridCtrl::TrackToolTip(CPoint point={...}) Riga 3321 C++ mfc90ud.dll!CMFCPropertyGridCtrl::PreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 3937 C++ > mfc90ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x003e0662, tagMSG * pMsg=0x00154e10) Riga 2946 + 0x14 byte C++ mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 233 + 0x12 byte C++ did someone experienced something similar? Am I missing something? Thank you in advance. Regards ing. Federico Fuga
-
Hi, I am developing a desktop application composed by the main exe and several modules (dll / plug-ins) . The main modules has a dialog where a CMFCPropertyGridCtrl is used to edit a collection of name/values pair. Also another dll has a wizard that make use of a property sheet where a CMFCPropertygridCtrl edits another collection of name/values pair. The application works as expected if only one of these dialog is executed. No matter what is the sequence, the second time the dialog is opened, the program asserts. I can open the same dialog more times, and it do not asserts, it asserts only when the second kind of dialog is opened. The dialog (both) asserts when the mouse pointer is passed over the CMFCPropertyGridCtrl Control, the stack traces from the TrackToolTip function inside the class. I have tracked the problem to the creation of the tooltip window: in CMFCPropertyGridCtrl::Init() the call to m_IPToolTip.Create(this) fails: BOOL CMFCPropertyGridToolTipCtrl::Create(CWnd* pWndParent) { ASSERT_VALID(pWndParent); m_pWndParent = pWndParent; if (m_strClassName.IsEmpty()) { m_strClassName = ::AfxRegisterWndClass(CS_SAVEBITS, ::LoadCursor(NULL, IDC_ARROW), (HBRUSH)(COLOR_BTNFACE + 1)); } return CreateEx(0, m_strClassName, _T(""), WS_POPUP, 0, 0, 0, 0, pWndParent->GetSafeHwnd(), (HMENU) NULL); } The first time this function executes, the CreateEx return TRUE and all works as expected. The second time, only if from a different module (DLL or EXE), m_strClassName is not empty and CreateEx fails with error code 0x00057f e.g. "Warning: Window creation failed: GetLastError returns 0x0000057F" that is ERROR_CANNOT_FIND_WND_CLASS. I do not use any tooltip, so I could also disable the tooltip feature. (stack trace of the assertion, when the mouse passes over the grid (WM_MOVE) ) mfc90ud.dll!CWnd::GetWindowRect(tagRECT * lpRect=0x0012f06c) Riga 116 + 0x2a byte C++ mfc90ud.dll!CMFCPropertyGridCtrl::TrackToolTip(CPoint point={...}) Riga 3321 C++ mfc90ud.dll!CMFCPropertyGridCtrl::PreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 3937 C++ > mfc90ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x003e0662, tagMSG * pMsg=0x00154e10) Riga 2946 + 0x14 byte C++ mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 233 + 0x12 byte C++ did someone experienced something similar? Am I missing something? Thank you in advance. Regards ing. Federico Fuga
You do not need to perform the check -
if (m_strClassName.IsEmpty())
AfxRegisterWndClass[^] will only register similar classes once. Read the remarks section of the documentation. Here is an excerpt from the documentation - If you call AfxRegisterWndClass multiple times with identical parameters, it only registers a class on the first call. Subsequent calls to AfxRegisterWndClass with identical parameters simply return the already-registered classname.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)
-
You do not need to perform the check -
if (m_strClassName.IsEmpty())
AfxRegisterWndClass[^] will only register similar classes once. Read the remarks section of the documentation. Here is an excerpt from the documentation - If you call AfxRegisterWndClass multiple times with identical parameters, it only registers a class on the first call. Subsequent calls to AfxRegisterWndClass with identical parameters simply return the already-registered classname.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)
«_Superman_» wrote:
You do not need to perform the check - if (m_strClassName.IsEmpty())
Hi _Superman_, thank you for your response. Yes, I know that check is useless, but it's not my code: as you can see, it's the source code of the CMFCPropertyGridCtrl class, in the Visual Studio 2008 MFC Feature Pack. I should try to remove that check -- m_strClassName is a static member, so it's shared between DLL and EXE; maybe the registration of the control depends on the hInstance of the module calling the Create() function, so it's failing on the second call because it has been registered from another instance. But this requires to recompile all the MFC / feature pack...? Note that calling Create() from a third DLL do not solve the issue. Thank you again
-
«_Superman_» wrote:
You do not need to perform the check - if (m_strClassName.IsEmpty())
Hi _Superman_, thank you for your response. Yes, I know that check is useless, but it's not my code: as you can see, it's the source code of the CMFCPropertyGridCtrl class, in the Visual Studio 2008 MFC Feature Pack. I should try to remove that check -- m_strClassName is a static member, so it's shared between DLL and EXE; maybe the registration of the control depends on the hInstance of the module calling the Create() function, so it's failing on the second call because it has been registered from another instance. But this requires to recompile all the MFC / feature pack...? Note that calling Create() from a third DLL do not solve the issue. Thank you again
No No No.... Please do not compile the MFC code. I didn't realize it was in the MFC code base. MFC code is properly tested. The problem could be else where. Are you able to debug and reach the problem?
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) -
No No No.... Please do not compile the MFC code. I didn't realize it was in the MFC code base. MFC code is properly tested. The problem could be else where. Are you able to debug and reach the problem?
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)No problem, I wasn't thinking that recompiling the MFC would solve the issue :-) The good news is that I have built a setup package using inno setup, and when installing on a plain Windows XP HE box the latest x86redist package downloaded from microsoft, the application works correctly. The bad news is that I do not know why. The "working" mfc package has version number 9.0.30729.1, the package installed on my development box (and crashing) has the 9.0.30729.4148. This one seems to be an updated version, dated july 2009 (the working one is dated 2008). I frankly expected that the older one was on my development box... So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application? Any comment? Thank you again Federico
-
No problem, I wasn't thinking that recompiling the MFC would solve the issue :-) The good news is that I have built a setup package using inno setup, and when installing on a plain Windows XP HE box the latest x86redist package downloaded from microsoft, the application works correctly. The bad news is that I do not know why. The "working" mfc package has version number 9.0.30729.1, the package installed on my development box (and crashing) has the 9.0.30729.4148. This one seems to be an updated version, dated july 2009 (the working one is dated 2008). I frankly expected that the older one was on my development box... So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application? Any comment? Thank you again Federico
f.fuga wrote:
So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application?
It is highly unlikely that the library is broken. It should be some problem with your application. You should try and debug it.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) -
f.fuga wrote:
So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application?
It is highly unlikely that the library is broken. It should be some problem with your application. You should try and debug it.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)«_Superman_» wrote:
It is highly unlikely that the library is broken. It should be some problem with your application. You should try and debug it.
I agree with you. I have checked the libraries version, both release and debug are ok. I think that Release version of my program works as expected because, of course, ASSERT() has only means when compiling in debug mode. From a practical approach, I should ignore the problem - the Release works. But I suspect that I will find again this problem in the future. So I will keep search for a solution. Do you know any issue when using some MFC classes from DLL and EXE ? I know the "AFX_MANAGE_STATE(AfxGetStaticModuleState());" call needed when accessing resources, I suspect a similar problem... Thank you Federico
-
Hi, I am developing a desktop application composed by the main exe and several modules (dll / plug-ins) . The main modules has a dialog where a CMFCPropertyGridCtrl is used to edit a collection of name/values pair. Also another dll has a wizard that make use of a property sheet where a CMFCPropertygridCtrl edits another collection of name/values pair. The application works as expected if only one of these dialog is executed. No matter what is the sequence, the second time the dialog is opened, the program asserts. I can open the same dialog more times, and it do not asserts, it asserts only when the second kind of dialog is opened. The dialog (both) asserts when the mouse pointer is passed over the CMFCPropertyGridCtrl Control, the stack traces from the TrackToolTip function inside the class. I have tracked the problem to the creation of the tooltip window: in CMFCPropertyGridCtrl::Init() the call to m_IPToolTip.Create(this) fails: BOOL CMFCPropertyGridToolTipCtrl::Create(CWnd* pWndParent) { ASSERT_VALID(pWndParent); m_pWndParent = pWndParent; if (m_strClassName.IsEmpty()) { m_strClassName = ::AfxRegisterWndClass(CS_SAVEBITS, ::LoadCursor(NULL, IDC_ARROW), (HBRUSH)(COLOR_BTNFACE + 1)); } return CreateEx(0, m_strClassName, _T(""), WS_POPUP, 0, 0, 0, 0, pWndParent->GetSafeHwnd(), (HMENU) NULL); } The first time this function executes, the CreateEx return TRUE and all works as expected. The second time, only if from a different module (DLL or EXE), m_strClassName is not empty and CreateEx fails with error code 0x00057f e.g. "Warning: Window creation failed: GetLastError returns 0x0000057F" that is ERROR_CANNOT_FIND_WND_CLASS. I do not use any tooltip, so I could also disable the tooltip feature. (stack trace of the assertion, when the mouse passes over the grid (WM_MOVE) ) mfc90ud.dll!CWnd::GetWindowRect(tagRECT * lpRect=0x0012f06c) Riga 116 + 0x2a byte C++ mfc90ud.dll!CMFCPropertyGridCtrl::TrackToolTip(CPoint point={...}) Riga 3321 C++ mfc90ud.dll!CMFCPropertyGridCtrl::PreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 3937 C++ > mfc90ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x003e0662, tagMSG * pMsg=0x00154e10) Riga 2946 + 0x14 byte C++ mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 233 + 0x12 byte C++ did someone experienced something similar? Am I missing something? Thank you in advance. Regards ing. Federico Fuga
Hey, I encountered the exactly same problem while working with CMFCPropertyGridCtrl in my DLL project. After many trial, i found a way to use CMFCPropertyGridCtrl in DLL without this error. All you have to do is Create a derived class of CMFCPropertyGridToolTipCtrl(),Make its protected static variable "m_strClassName" NULL in Constructor. for example; ////////////////////////////////////////////////////////////////////////////////// Class CMyToolTipCtrl::CMFCPropertyGridToolTipCtrl(); CMyToolTipCtrl::CMyToolTipCtrl() { m_strClassName = ""; } /////////////////////////////////////////////////////////////////////////////////// Now create ToolTipctrl from your CMFCPropertyGridToolTipCtrl() derived class on Init of the CMFCPropertyGridCtrl derived Class. for example, /////////////////////////////////////////////////////////////////////////////////// Class MyPropertyGridCtrl::CMFCPropertyGridCtrl(); void MyPropertyGridCtrl::Init() { CMyToolTipCtrl p_tooltip; p_tooltip.Create(this); } //////////////////////////////////////////////////////////////////////////////////////
There is always a way. Priyanka Oza.