CDialog crashing in an MFC DLL

I am developing a plug-in architecture for an MFC application using MFC-based DLLs.  Everything works perfectly except when I bring up a CDialog object from within a DLL.  The dialog itself functions correctly, but when MFC destroys the dialog I get the well-known "Access violation reading location…" crash error in this specific function within MFC

void* CMapPtrToPtr::GetValueAt(void* key) cons

Looking at the stack trace it appears that MFC keeps handle maps for temporary and permanant windows.  For this particular case the crash occurs when MFC is checking the validity of the dialog's CWnd object.  Here is the MFC function where this crash occurs

void CWnd::AssertValid() cons

    if (m_hWnd == NULL
        return;     // null (unattached) windows are vali

    // check for special wnd??? value
    ASSERT(HWND_TOP == NULL);       // same as deskto
    if (m_hWnd == HWND_BOTTOM
        ASSERT(this == &CWnd::wndBottom)
    else if (m_hWnd == HWND_TOPMOST
        ASSERT(this == &CWnd::wndTopMost)
    else if (m_hWnd == HWND_NOTOPMOST
        ASSERT(this == &CWnd::wndNoTopMost)
    els
    
        // should be a normal windo
        ASSERT(::IsWindow(m_hWnd))

        // should also be in the permanent or temporary handle ma
        CHandleMap* pMap = afxMapHWND()
        ASSERT(pMap != NULL)

        CObject* p
        ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||              <<<< My DLL crashes accessing these maps
            (p = pMap->LookupTemporary(m_hWnd)) != NULL)
        ASSERT((CWnd*)p == this);   // must be u
    


Doing some more investigating I have discovered that no matter what I do, these maps are invalid in the DLL and MFC crashes when it tries to access them at any time.  If I do not open windows from the DLL everything else in MFC seems to work flawlessly.  I have the same problem whether I create a DLL that uses MFC or an MFC extension DLL

Here is the function in my DLL that brings up the CDialog

// Show the editing dialog (if any) for this objec
void CRolloverPlugInImpl::ShowEditorImpl(HWND hParent

    AFX_MANAGE_STATE(AfxGetStaticModuleState())

    CWnd* pParentWnd = 0
    if (hParent != 0
    
        pParentWnd = CWnd::FromHandle(hParent)
    

    CRolloverGraphicDlg dlg(pParentWnd)
    dlg.SetParms(this);                                 // This allows the dialog's code to read / write settings from this clas
    dlg.DoModal()

    delete pParentWnd


I am using Visual Studio .Net 2003.  MFC is being used in a shared DLL for both the application and the DLL.  The applciation is single-threaded for now, both the application and the DLLs are linked to the multi-threaded DLL runtime library

Is there anybody out there who can tell me what I am doing wrong

Regards
Don Jorda

0
anonymous (74725)
6/5/2004 2:46:01 PM
vc.mfc 33608 articles. 0 followers. Follow

11 Replies
2027 Views

Similar Articles

[PageSpeed] 12

"J. Frank Parnel" <anonymous@discussions.microsoft.com> wrote in message
news:17DC2E47-817C-43A2-B2F5-84063A7C8C41@microsoft.com...
> I am developing a plug-in architecture for an MFC application using
MFC-based DLLs.  Everything works perfectly except when I bring up a CDialog
object from within a DLL.  The dialog itself functions correctly, but when
MFC destroys the dialog I get the well-known "Access violation reading
location�" crash error in this specific function within MFC:
>
> void* CMapPtrToPtr::GetValueAt(void* key) const
>
> Looking at the stack trace it appears that MFC keeps handle maps for
temporary and permanant windows.  For this particular case the crash occurs
when MFC is checking the validity of the dialog's CWnd object.  Here is the
MFC function where this crash occurs:
>
> void CWnd::AssertValid() const
> {
>     if (m_hWnd == NULL)
>         return;     // null (unattached) windows are valid
>
>     // check for special wnd??? values
>     ASSERT(HWND_TOP == NULL);       // same as desktop
>     if (m_hWnd == HWND_BOTTOM)
>         ASSERT(this == &CWnd::wndBottom);
>     else if (m_hWnd == HWND_TOPMOST)
>         ASSERT(this == &CWnd::wndTopMost);
>     else if (m_hWnd == HWND_NOTOPMOST)
>         ASSERT(this == &CWnd::wndNoTopMost);
>     else
>     {
>         // should be a normal window
>         ASSERT(::IsWindow(m_hWnd));
>
>         // should also be in the permanent or temporary handle map
>         CHandleMap* pMap = afxMapHWND();
>         ASSERT(pMap != NULL);
>
>         CObject* p;
>         ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
<<<< My DLL crashes accessing these maps.
>             (p = pMap->LookupTemporary(m_hWnd)) != NULL);
>         ASSERT((CWnd*)p == this);   // must be us
>     }
> }
>
> Doing some more investigating I have discovered that no matter what I do,
these maps are invalid in the DLL and MFC crashes when it tries to access
them at any time.  If I do not open windows from the DLL everything else in
MFC seems to work flawlessly.  I have the same problem whether I create a
DLL that uses MFC or an MFC extension DLL.
>
> Here is the function in my DLL that brings up the CDialog:
>
> // Show the editing dialog (if any) for this object
> void CRolloverPlugInImpl::ShowEditorImpl(HWND hParent)
> {
>     AFX_MANAGE_STATE(AfxGetStaticModuleState());
>
>     CWnd* pParentWnd = 0;
>     if (hParent != 0)
>     {
>         pParentWnd = CWnd::FromHandle(hParent);
>     }
>
>     CRolloverGraphicDlg dlg(pParentWnd);
>     dlg.SetParms(this);                                 // This allows the
dialog's code to read / write settings from this class
>     dlg.DoModal();
>
>     delete pParentWnd;
> }
>
> I am using Visual Studio .Net 2003.  MFC is being used in a shared DLL for
both the application and the DLL.  The applciation is single-threaded for
now, both the application and the DLLs are linked to the multi-threaded DLL
runtime library.
>
> Is there anybody out there who can tell me what I am doing wrong?

Not sure, but I'm very suspicious of that 'delete pParentWnd' line. What
happens if you remove it?
-- 
Jeff Partch [VC++ MVP]


0
jeffp (1711)
6/5/2004 3:08:34 PM
The crash occcurs long before the 'delete pParentWnd' line.  In fact, the application never returns from DoModal()

The crash occurs while MFC is closing the dialog above it either by my code explicitly calling CDialog::OnOK or having MFC handle all the dialog messages itself.  Here's the stack trace from of the crash from the originating function "ShowEditorImpl" to where it fails.  Note that my OnOK handler RolloverPlugIn.dll!CRolloverGraphicDlg::OnOK()  calls the one in CDialog..

>	mfc71d.dll!CMapPtrToPtr::GetValueAt(void * key=0x0005088a)  Line 191 + 0x3	C+
 	mfc71d.dll!CHandleMap::LookupPermanent(void * h=0x0005088a)  Line 116 + 0x16	C+
 	mfc71d.dll!CWnd::AssertValid()  Line 888 + 0xf	C+
 	mfc71d.dll!CDialog::AssertValid()  Line 780	C+
 	mfc71d.dll!AfxAssertValidObject(const CObject * pOb=0x00e8f538, const char * lpszFileName=0x7c144c68, int nLine=4221)  Line 104	C+
 	mfc71d.dll!CDataExchange::CDataExchange(CWnd * pDlgWnd=0x00e8f538, int bSaveAndValidate=1)  Line 4222	C+
 	mfc71d.dll!CWnd::UpdateData(int bSaveAndValidate=1)  Line 4189	C+
 	mfc71d.dll!CDialog::OnOK()  Line 685 + 0xa	C+
 	RolloverPlugIn.dll!CRolloverGraphicDlg::OnOK()  Line 244	C+
 	mfc71d.dll!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x00e8f538, unsigned int nID=1, int nCode=0, void (void)* pfn=0x7c181900, void * pExtra=0x00000000, unsigned int nSig=53, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 89	C+
 	mfc71d.dll!CCmdTarget::OnCmdMsg(unsigned int nID=1, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 396 + 0x27	C+
 	mfc71d.dll!CDialog::OnCmdMsg(unsigned int nID=1, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 88 + 0x18	C+
 	mfc71d.dll!CWnd::OnCommand(unsigned int wParam=1, long lParam=264300)  Line 2550	C+
 	mfc71d.dll!CWnd::OnWndMsg(unsigned int message=273, unsigned int wParam=1, long lParam=264300, long * pResult=0x00e8ef3c)  Line 1759 + 0x1c	C+
 	mfc71d.dll!CWnd::WindowProc(unsigned int message=273, unsigned int wParam=1, long lParam=264300)  Line 1745 + 0x1e	C+
 	mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x00e8f538, HWND__ * hWnd=0x0005088a, unsigned int nMsg=273, unsigned int wParam=1, long lParam=264300)  Line 241 + 0x1a	C+
 	mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x0005088a, unsigned int nMsg=273, unsigned int wParam=1, long lParam=264300)  Line 389	C+
 	RolloverPlugIn.dll!AfxWndProcDllStatic(HWND__ * hWnd=0x0005088a, unsigned int nMsg=273, unsigned int wParam=1, long lParam=264300)  Line 53 + 0x15	C+
 	user32.dll!77d43a50() 
 	user32.dll!77d43b1f() 
 	user32.dll!77d43b33() 
 	user32.dll!77d45453() 
 	user32.dll!77d454b4() 
 	comctl32.dll!71981575() 
 	comctl32.dll!7198164e() 
 	comctl32.dll!71983850() 
 	mfc71d.dll!CThreadLocal<_AFX_THREAD_STATE>::GetData()  Line 177 + 0xd	C+
 	mfc71d.dll!_AfxMsgFilterHook(int code=0, unsigned int wParam=15266268, long lParam=2010397264)  Line 813 + 0x20	C+
 	user32.dll!77d47fc4() 
 	user32.dll!77d43b1f() 
 	user32.dll!77d43d79() 
 	user32.dll!77d6669d() 
 	user32.dll!77d43ddf() 
 	user32.dll!77d4b1f5() 
 	user32.dll!77d65906() 
 	mfc71d.dll!CWnd::IsDialogMessageA(tagMSG * lpMsg=0x0006ba90)  Line 200	C+
 	mfc71d.dll!CWnd::PreTranslateInput(tagMSG * lpMsg=0x0006ba90)  Line 4512	C+
 	mfc71d.dll!CDialog::PreTranslateMessage(tagMSG * pMsg=0x0006ba90)  Line 83	C+
 	mfc71d.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x0005088a, tagMSG * pMsg=0x0006ba90)  Line 3129 + 0x12	C+
 	mfc71d.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0006ba90)  Line 238 + 0x12	C+
 	mfc71d.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg=0x0006ba90)  Line 795 + 0x9	C+
 	mfc71d.dll!AfxPreTranslateMessage(tagMSG * pMsg=0x0006ba90)  Line 257 + 0xf	C+
 	mfc71d.dll!AfxInternalPumpMessage()  Line 183 + 0x18	C+
 	mfc71d.dll!CWinThread::PumpMessage()  Line 916	C+
 	mfc71d.dll!AfxPumpMessage()  Line 195 + 0xb	C+
 	mfc71d.dll!CWnd::RunModalLoop(unsigned long dwFlags=4)  Line 4566 + 0x5	C+
 	mfc71d.dll!CDialog::DoModal()  Line 527 + 0xc	C+
 	RolloverPlugIn.dll!CRolloverPlugInImpl::ShowEditorImpl(HWND__ * hParent=0x00040794)  Line 719	C+
 
0
anonymous (74725)
6/5/2004 4:31:09 PM
Are you using static linking? That can often be the cause of these bugs. You must elect to
use the shared DLL, and you cannot mix debug and release executables and DLLs.
			joe

On Sat, 5 Jun 2004 07:46:01 -0700, J. Frank Parnel <anonymous@discussions.microsoft.com>
wrote:

>I am developing a plug-in architecture for an MFC application using MFC-based DLLs.  Everything works perfectly except when I bring up a CDialog object from within a DLL.  The dialog itself functions correctly, but when MFC destroys the dialog I get the well-known "Access violation reading location�" crash error in this specific function within MFC:
>
>void* CMapPtrToPtr::GetValueAt(void* key) const
>
>Looking at the stack trace it appears that MFC keeps handle maps for temporary and permanant windows.  For this particular case the crash occurs when MFC is checking the validity of the dialog's CWnd object.  Here is the MFC function where this crash occurs:
>
>void CWnd::AssertValid() const
>{
>    if (m_hWnd == NULL)
>        return;     // null (unattached) windows are valid
>
>    // check for special wnd??? values
>    ASSERT(HWND_TOP == NULL);       // same as desktop
>    if (m_hWnd == HWND_BOTTOM)
>        ASSERT(this == &CWnd::wndBottom);
>    else if (m_hWnd == HWND_TOPMOST)
>        ASSERT(this == &CWnd::wndTopMost);
>    else if (m_hWnd == HWND_NOTOPMOST)
>        ASSERT(this == &CWnd::wndNoTopMost);
>    else
>    {
>        // should be a normal window
>        ASSERT(::IsWindow(m_hWnd));
>
>        // should also be in the permanent or temporary handle map
>        CHandleMap* pMap = afxMapHWND();
>        ASSERT(pMap != NULL);
>
>        CObject* p;
>        ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||              <<<< My DLL crashes accessing these maps.
>            (p = pMap->LookupTemporary(m_hWnd)) != NULL);
>        ASSERT((CWnd*)p == this);   // must be us
>    }
>}
>
>Doing some more investigating I have discovered that no matter what I do, these maps are invalid in the DLL and MFC crashes when it tries to access them at any time.  If I do not open windows from the DLL everything else in MFC seems to work flawlessly.  I have the same problem whether I create a DLL that uses MFC or an MFC extension DLL.
>
>Here is the function in my DLL that brings up the CDialog:
>
>// Show the editing dialog (if any) for this object
>void CRolloverPlugInImpl::ShowEditorImpl(HWND hParent)
>{
>    AFX_MANAGE_STATE(AfxGetStaticModuleState());
>
>    CWnd* pParentWnd = 0;
>    if (hParent != 0)
>    {
>        pParentWnd = CWnd::FromHandle(hParent);
>    }
>
>    CRolloverGraphicDlg dlg(pParentWnd);
>    dlg.SetParms(this);                                 // This allows the dialog's code to read / write settings from this class
>    dlg.DoModal();
>
>    delete pParentWnd;
>}
>
>I am using Visual Studio .Net 2003.  MFC is being used in a shared DLL for both the application and the DLL.  The applciation is single-threaded for now, both the application and the DLLs are linked to the multi-threaded DLL runtime library.
>
>Is there anybody out there who can tell me what I am doing wrong?
>
>Regards,
>Don Jordan

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15977)
6/5/2004 6:14:38 PM
"Don Jordan" <anonymous@discussions.microsoft.com> wrote in message
news:2043E358-0497-4F27-8B40-88171E1A4C7C@microsoft.com...
> The crash occcurs long before the 'delete pParentWnd' line.  In fact, the
application never returns from DoModal().
>
> The crash occurs while MFC is closing the dialog above it either by my
code explicitly calling CDialog::OnOK or having MFC handle all the dialog
messages itself.  Here's the stack trace from of the crash from the
originating function "ShowEditorImpl" to where it fails.  Note that my OnOK
handler RolloverPlugIn.dll!CRolloverGraphicDlg::OnOK()  calls the one in
CDialog...
>
> > mfc71d.dll!CMapPtrToPtr::GetValueAt(void * key=0x0005088a)  Line 191 +
0x3 C++
>   mfc71d.dll!CHandleMap::LookupPermanent(void * h=0x0005088a)  Line 116 +
0x16 C++
>   mfc71d.dll!CWnd::AssertValid()  Line 888 + 0xf C++
>   mfc71d.dll!CDialog::AssertValid()  Line 780 C++
>   mfc71d.dll!AfxAssertValidObject(const CObject * pOb=0x00e8f538, const
char * lpszFileName=0x7c144c68, int nLine=4221)  Line 104 C++
>   mfc71d.dll!CDataExchange::CDataExchange(CWnd * pDlgWnd=0x00e8f538, int
bSaveAndValidate=1)  Line 4222 C++
>   mfc71d.dll!CWnd::UpdateData(int bSaveAndValidate=1)  Line 4189 C++
>   mfc71d.dll!CDialog::OnOK()  Line 685 + 0xa C++
>   RolloverPlugIn.dll!CRolloverGraphicDlg::OnOK()  Line 244 C++


Well, this is probably a waste of time too, but because it seems to be
working up to here: are you doing anything in your OnOK handler?
-- 
Jeff Partch [VC++ MVP]


0
jeffp (1711)
6/5/2004 6:17:48 PM
Jeff and Joseph

The only thing my OnOK handler does is set a few flags in the plug-in.  I removed all code from my handler to have it only call CDialog::OnOK and it still crashes.  As a matter of fact, I still get the crash when I remove my OnOK handler entirely.  The crash is in a different section of MFC, but it still fails the same way when accessing the same window handle maps

The application and the DLL are both using MFC as a shared DLL--there is no static linking.  Their debug and release versions all match.  I wish it was something that simple. :-

Since MFC has a lot of things going on in the background, like the window handle maps it maintains, there may be something subtle, yet fundamentally wrong about how I am setting things up.  Please allow me to give an outline of how this plug-in architecture works and perhaps you could point out some areas I should investigate

I can't reveal the application I am working on since it would give our competitors information about a future release of an already established product. ;-)  However, I can say that we are using a page-layout metaphor where the user can drag and manipulate objects on the page.  We have graphic objects, text objects, etc. that are subclasses of MFC’s CObject.  You get the picture

Anyway, I am working on a plug-in object for the page whose function and behavior is determined by whatever DLL is loaded for it.  The plug-in has an implementation interface defined that must be provided by the DLL.   This interface defines functions for drawing the object on the page, serialization, etc., etc.  The only exported function from the DLL is a factory call that creates an instance of a C++ class that implements this interface.  The DLL’s factory function returns an IUnknown pointer which the application’s plug-in object performs QueryInterface calls to get the interface it needs

All of the reference counting for the IUnknown object and the DLL seem to be working correctly so nothing appears to be prematurely released

There are no MFC objects being passed back and forth between the application and the DLL at this point.  I doubt if that would be causing this problem since I get the same crash even if I implement my DLL as an MFC extension

Perhaps using this approach with MFC is wrong.  I don’t know.  Any suggestions or ideas would be appreciated.  If you need more detailed information or code snippets I would be glad to provide them

-Don Jorda


0
anonymous (74725)
6/6/2004 1:26:03 AM
The usual cause of failing to pick up things from the handle map is having two handle
maps, which is usually caused by static linking. So that's ruled out.

Overall, what you are doing sounds perfectly reasonable. But in re-reading it, I think I
found the bug.

That deletion of the handle you get from the FromHandle, however, is extremely suspicious.
Why are you deleting it? If it is in the permanent handle map, this would almost certainly
cause the crash; if it is in the temporary handle map, you will screw up the temporary
handle map. Why do you think you need the delete operation?

Also, you should not assign 0 to pointers; you should always use NULL. It is cleaner
style, and makes it clear that pointers, and not integers, are what is being dealt with.
					joe

On Sat, 5 Jun 2004 18:26:03 -0700, "Don Jordan" <anonymous@discussions.microsoft.com>
wrote:

>Jeff and Joseph:
>
>The only thing my OnOK handler does is set a few flags in the plug-in.  I removed all code from my handler to have it only call CDialog::OnOK and it still crashes.  As a matter of fact, I still get the crash when I remove my OnOK handler entirely.  The crash is in a different section of MFC, but it still fails the same way when accessing the same window handle maps.
>
>The application and the DLL are both using MFC as a shared DLL--there is no static linking.  Their debug and release versions all match.  I wish it was something that simple. :-|
>
>Since MFC has a lot of things going on in the background, like the window handle maps it maintains, there may be something subtle, yet fundamentally wrong about how I am setting things up.  Please allow me to give an outline of how this plug-in architecture works and perhaps you could point out some areas I should investigate.
>
>I can't reveal the application I am working on since it would give our competitors information about a future release of an already established product. ;-)  However, I can say that we are using a page-layout metaphor where the user can drag and manipulate objects on the page.  We have graphic objects, text objects, etc. that are subclasses of MFC�s CObject.  You get the picture.
>
>Anyway, I am working on a plug-in object for the page whose function and behavior is determined by whatever DLL is loaded for it.  The plug-in has an implementation interface defined that must be provided by the DLL.   This interface defines functions for drawing the object on the page, serialization, etc., etc.  The only exported function from the DLL is a factory call that creates an instance of a C++ class that implements this interface.  The DLL�s factory function returns an IUnknown pointer which the application�s plug-in object performs QueryInterface calls to get the interface it needs.
>
>All of the reference counting for the IUnknown object and the DLL seem to be working correctly so nothing appears to be prematurely released.
>
>There are no MFC objects being passed back and forth between the application and the DLL at this point.  I doubt if that would be causing this problem since I get the same crash even if I implement my DLL as an MFC extension.
>
>Perhaps using this approach with MFC is wrong.  I don�t know.  Any suggestions or ideas would be appreciated.  If you need more detailed information or code snippets I would be glad to provide them.
>
>-Don Jordan
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15977)
6/6/2004 6:45:53 AM
Joe

Thank you for your response

Unfortunately for me, the program crashes in MFC before it returns from DoModal().  I have yet to have the code execute that far to reach the deletion of the CWnd pointer.  <grin

Your suspicion about the deletion of the pointer is well-founded since the code snippet I posted would have the parent CWnd object deleted before the CDialog object is destroyed when it goes out of scope.  For the sake of brevity, I only posted the relevant part of the function in question.  To clear up any confusion I may be causing here is the function in its entirety

void CRolloverPlugInImpl::ShowEditorImpl(HWND hParent

    AFX_MANAGE_STATE(AfxGetStaticModuleState())

    CWnd* pParentWnd = 0
    if (hParent
    
        pParentWnd = CWnd::FromHandle(hParent)
    

    WORD count = GetFrameCountImpl(FALSE)
    if (count == 3
    
        CRolloverGraphicDlg dlg(pParentWnd)
        dlg.SetParms(this);                // This allows the dialog's code to read / write settings from this clas
        dlg.DoModal()
        UpdatePlaceHolderGraphic()
    
    else if (count == 1
    
        // TODO: handle this case with the other modal properties dialog
    

    delete pParentWnd


I edited the function down to prevent any confusion caused by superfluous code and in the process caused the very thing I was trying to avoid in the first place!  Please accept my apology.  In any event, the deletion of pParentWnd should not be a problem since, as you can now see, the CRolloverGraphicDlg object would be destroyed by the time the delete operator is executed

I have one last idea that may be a potential problem.  I have shared library (*.lib) that contains common utility functions and type definitions that are used by both the application and the plug-in DLL.  There are a few functions in there that use MFC classes (CObject and CString) but nothing that uses any windowing.  This library is statically linked to the application and the DLL projects.  In the project that builds the library, MFC is also used as a shared DLL.  I am grasping at straws here.  Could this be a problem

I understand your reasoning about the usage of the "NULL" preprocessor symbol for pointers.  In the "old days" of my cross-platform C++ development using NULL could spell disaster since it was defined in various ways on different platforms.  Using a literal numeric zero was the only way to guarntee conversion to a true null value regardless of the pointer type.  This does not exist as a technical issue today, but some circles I run in believe that "real C++ programmers don't use NULL."  I am not one of them, but it keeps me out of trouble. ;-

Thanks for your time and help

Don Jordan
0
anonymous (74725)
6/6/2004 6:06:02 PM
"Don Jordan" <anonymous@discussions.microsoft.com> wrote in message
news:B621B5EE-3196-490E-807E-FC636CB6A21A@microsoft.com...
> Unfortunately for me, the program crashes in MFC before it returns from
DoModal().  I have yet to have the code execute that far to reach the
deletion of the CWnd pointer.  <grin>

Dan, sorry I can't help with your real problem, but as both Joe and I have
said: remove that delete! CWnd::FromHandle returns a pointer that is owned
and managed by the framework.
-- 
Jeff Partch [VC++ MVP]


0
jeffp (1711)
6/6/2004 6:51:01 PM
The delete shall be removed!
0
anonymous (74725)
6/6/2004 7:11:03 PM
First of all, picture someone slapping themselves on the forehead mumbling "dummy, dummy" to himself--that's me.  I should have *not* used FromHandle to create a temporary CWnd object for the parent window.  Here is the solution that eliminates the crash

void CRolloverPlugInImpl::ShowEditorImpl(HWND hParent

    AFX_MANAGE_STATE(AfxGetStaticModuleState())

    CWnd* pParentWnd = 0
    if (hParent
    
        if (pParentWnd = new CWnd()
        
            if (!pParentWnd->Attach(hParent)
            
                delete pParentWnd
                pParentWnd = 0
            
        
    

    WORD count = GetFrameCountImpl(FALSE)
    if (count == 3
    
        CRolloverGraphicDlg dlg(pParentWnd)
        dlg.SetParms(this)
        dlg.DoModal()
        UpdatePlaceHolderGraphic()
    
    else if (count == 1
    
        // TODO: handlw the other case nex
    

    if (pParentWnd
    
        pParentWnd->Detach()
        delete pParentWnd
    


When you told me, again, that the CWnd object produced by FromHandle is "owned by the framework" it finally sunk in what I was doing wrong.  Apparently, the framework does not like FromHandle produced CWnd objects being used as parent windows in this situation.  ARRGH!  I just *hate*stuff like this

Thanks guys for beating it into my head

Regards
Don Jordan
0
anonymous (74725)
6/6/2004 7:36:02 PM
On Sun, 6 Jun 2004 12:36:02 -0700, "Don Jordan" <anonymous@discussions.microsoft.com>
wrote:

>First of all, picture someone slapping themselves on the forehead mumbling "dummy, dummy" to himself--that's me. 

WRONG! That's ANY engineer. That's how you recognize an engineer: they have sloped
foreheads from hitting them so often. My forehead, like that of most engineers, is
calloused.

Read my essay on attach/detach on my MVP Tips site. This is one of those places where the
impedence mismatch between MFC and Windows becomes very evident. The problem is not using
it as a parent window as much as the fact that deletion of the object also destroys the
associated window. 
				joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15977)
6/7/2004 2:38:15 AM
Reply:

Similar Artilces:

Creating a CDialog derived class for a Dialog??
I am trying to convert a project from Win32 to MFC. I created a new dialog resource, but when I try to do the right-click add class thing from the dialog editor, it doesn't do anything. I am using VS.NET 2003 Pro. In the dialog that pops up to create the new class, I change it to derive from CDialog, it already has the ID for my dialogbox resource selected, and I enter a new class name, and it generates the .h and .cpp names. I click Finish and NOTHING happens. I try it again from the main menu, but this time it pops an error box saying "Object Required". I am stumpe...

Outlook 2002 crashes when exporting data
When I use the "Import and Export" option from the File menu and choose "Export to a file" , Outlook 2002 crashes in module RM.DLL. I'm running all of the latest service packs for both Windows XP and MS Office Pro 2002. Any clues that will help me identify the cause of this problem will be greatly appreciated. Thanks, Jack ...

Changing an MFC CDialog to a control inside another CDialog
Hi everyone, In my MFC application i have a CDialog window which is shown (modal) when clicking on a specific button. After some changes in my application, I decided that I need the controls on that secondary CDialog to be shown always inside the main window. Is there a way to change the secondary CDialog derived window to a control (like CStatic, etc) inside my main window, and not a child window? Maybe changing the devired class (CDialog to CStatic)? or changing some properties in the CDialog and calling its Create method with a specific parameters? Thanks. Menny wrote: > Hi everyone,...

Exchange Crash -- all we have is the ispriv.edb file
Hello all -- A client of mine never did any exchange 2003 backups, but did copy over the ispriv.edb file over to an external USB harddrive. All we want to do is pull the email out of that directory (8GB file) and put it into .pst files. Then, Ill reinstall Exchange, and open each person's mail box and copy the contents of each .PST file back to the server. My question is: If I only have the ISPRIV.EDB file, how do I get mail out of it ? Is there some super cool easy to use tool for this? ;-) Any help appreciated!! Sincerely, Blake http://wm.quest.com/products/recoverymanage...

My file crashed!
I had an Excel file I was using for budgeting, and had spent at least a year working on it, improving it, and all the sudden, it's corrupted, and I've lost all my formatting. Any idea how to get it back? What version of XL are you using? XL02/03 have some fairly advanced recovery capability compared to other XL versions. I've also been successful recovering corrupt files using OpenOffice: http://openoffice.org Once you recover the file, you will of course also begin making frequent backups... In article <e79sg4#dEHA.2352@TK2MSFTNGP09.phx.gbl>, "tmoore4748...

CDialog
hi i want to create an open dialog box to select a folder When i used CFileDialog i could open only a file. CFileDialog cfdOpen(TRUE,NULL,NULL,OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,NULL,NULL); priya Hi priya To select a folder don't use CFileDialog use SHBrowseForFolder shell API. here is just an example BROWSEINFO bi; LPITEMIDLIST pidl; bi.hwndOwner = m_hWnd; bi.pidlRoot = NULL; bi.pszDisplayName = dir; bi.lpszTitle = dlgTitle; bi.ulFlags = BIF_RETURNONLYFSDIRS; bi.lpfn = NULL; bi.lParam = 0; pidl = SHBrowseForFolder(&a...

MFC to launch MsDev
I am running MsDev 7.1 I would like to from a MFC project use automation to launch MsDev then load a text file etc... The problem is that when I use the 'Add Class' and select 'MFC Class from Typelib' and then choose 'Microsoft Development Environment 7.0' type library I cannot determine what interface to generate the class for. There is no _Application interface or similar like there is for each of the Office applications. MSDN documentation regarding MsDev automation has not been updated (shame!), and I am at a loss. Ideas? - Marty ...

MS Outlook crash
Error reads: Your server has unexpectedly terminated the connection. Possible causes for this include server problems, network problems, or a long period of inactivity. Account: 'mail.comcast.net', Server: 'mail.comcast.net', Protocol: POP3, Port: 995, Secure(SSL): Yes, Error Number: 0x800CCC0F Change the port of the incoming server from 995 to 110, and uncheck the SSL option. Gary VanderMolen, Microsoft MVP (Mail) ------------------------------------------------------ "Thanx" wrote in message news:#jL0sktTLHA.796@TK2MSFTNGP02.phx.gbl... Error reads: You...

Sbs 2008 Console Crashes
Been working fine for a long time but now the console crashes. If I open console in safe mode it crashes when looking at the computers section. In the console log has: 17300] 100420.170833.5722: Admin: !!!!FATAL: Console shutting down due to unhandled exception: Exception has been thrown by the target of an invocation. [17300] 100420.170833.5742: Exception: Is the only way of sorting this out but repairine the console? Hello, Thanks for your post. Just for your reference, here is a related article from SBS blog: SBS console crashes when duplicate entries from AV produ...

IE crashing when using CRM 3
some users are experiencing a lot of IE crashes when using CRM3.0.5300.0 This is when clicking around the CRM and I have a screenshot of the CRM as it crashed if anyone needs this... The diagnostic is below: <?xml version="1.0" encoding="UTF-16"?> <DATABASE> <EXE NAME="iexplore.exe" FILTER="GRABMI_FILTER_PRIVACY"> <MATCHING_FILE NAME="HMMAPI.DLL" SIZE="38912" CHECKSUM="0xD85D870C" BIN_FILE_VERSION="6.0.2900.2180" BIN_PRODUCT_VERSION="6.0.2900.2180" PRODUCT_VERSION="6.00....

Excel crashes
We're running Excel 2003 with SP3 on Window XP sp3. I have a couple users experiencing frequent Excel crashes. One of them even got a report of Excel crashing when Excel wasn't even running. In both cases, when Excel is restrarted, it "recovers" files that they were not working on. Any clues? ~Jason Just a guess... Try changing the default printer to something else--even if you have to install a different printer driver for a printer that doesn't physically exist. I read somewhere that lots (most???) windows crashes are caused by bad printer driver...

The file gdiplus.dll is incompatible with Microsoft Outlook. Install Outlook again. #2
Windows XP Professional SP2 plus MS updates - I am staying clear of SP3 Outlook 2007 SP1 all MS updates installed Hi all I have had this message crop up on two occasions. Outlook restarts OK but the reading pane is missing. Has anybody else had this error and is there a fix for it? TIA Big Dave ...

MFC #3
What will be the best book to read the VC++ MFC in depth? "Programming Windows with MFC" by Jeff Prosise is pretty good. It is published by Microsoft Press w/ ISBN:1572316950 "HariKaran" <anonymous@discussions.microsoft.com> wrote in message news:0b3a01c39d3d$8ce4b2f0$a301280a@phx.gbl... > What will be the best book to read the VC++ MFC in depth? MFC Internals "HariKaran" <anonymous@discussions.microsoft.com> wrote in message news:0b3a01c39d3d$8ce4b2f0$a301280a@phx.gbl... > What will be the best book to read the VC++ MFC in depth? ...

Portfolio crash
As of yesterday, whenever I click on Portfolio on the toolbar, Money 2004 crashes with a short sound--no error message, no report to MS, no nothing. Any ideas? Spence In microsoft.public.money, Spence wrote: >As of yesterday, whenever I click on Portfolio on the >toolbar, Money 2004 crashes with a short sound--no error >message, no report to MS, no nothing. Any ideas? See if you can navigate around sample.mny. If so, consider using File->MoneyFile->StandardFileRepair. If not, reinstall Money. I get same error as of last week. I have tried the standard repair but no...

Populate MFC Datagrid control from SQL Server
Hi, I am using the following code to transfer data from a SQL database to a MFC Datagrid control CCommand<CDynamicAccessor, CRowset> dbCommand; try { Recordset20Ptr spRs; ADORecordsetConstructionPtr spADOsCt; CDBPropSet propset(DBPROPSET_ROWSET); propset.AddProperty(DBPROP_CLIENTCURSOR, true); propset.AddProperty(DBPROP_IRowsetChange, true); propset.AddProperty(DBPROP_UPDATABILITY, DBPROPVAL_UP_CHANGE | DBPROPVAL_UP_INSERT | DBPROPVAL_UP_DELETE); CString sCommand; ...

How to DoModal a CDialog initially invisible
Hi all, Under specific circunstances, I need to start my dialog-based app invisible. Unfortunately, as expected, when I call DoModal, the window is always visible, whatever I do (uncheck the visible box on dialog properties in the resources, ModifyStyle in OnInitDialog, ...) Is there a clean way to do that ? If not, what could be the cleanest dirty way ? ;) Thanks. -- Dansk Just don't call DoModal(). Place the code that you need to execute into a separate function in the same dialog class and call that function. class MyDialog : public CDialog { public: MyDialog() : CDia...

Outlook 2007 Crashes when trying to print Calendar
Hi, I used to be able to successfully print the month view of my calendar, but lately it crashes MS Outlook every time I try to print it. I can still print Day or Week calendar views as well as Month calendar using a list view as opposed to the normal cakendar view. I am running Windows 7 Evaluation copy & it doesn't seem to matter which printer I have set as the default, it still crashes. I have uninstalled & re-installed MS Office, but the problem still persists. Any help / suggestions would be much appreciated. Thanks & Regards, Stephen What error ...

Embedding font causes Word 2003 to crash
I'm sending a document to someone, and the letterhead has Lucida Casual font, so I want to embed that so it looks correct on the other computer. I click Tools, Options, Save, and choose Embed Fonts. I've also tried choosing to only embed the characters that are used, and not to embed common system fonts. When I then save the document, Word crashes and shuts down. I tell it to report the problem, but it tries and tries and never finishes. When I come back into Word, there is no evidence that I even had the document open before. Help! -- Terri ...

Trouble with CDialog DoModal()
I created a new dialog with two buttons and a richedit area. I used the wizard to create a new class and the code. Now, I got: ///////////////////////////////////////////////////////////////////////////// // CStatDialog dialog CStatDialog::CStatDialog(CWnd* pParent /*=NULL*/) : CDialog(CStatDialog::IDD, pParent) { //{{AFX_DATA_INIT(CStatDialog) m_StatisticText = _T(""); //}}AFX_DATA_INIT } void CStatDialog::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CStatDialog) DDX_Text(pDX, IDC_RICHEDIT1, m_StatisticText); //}}AFX_DATA_MAP } ...

New to VC/MFC
Wonder, what made someone to name the following things?! ERROR_SUCCESS CCheckListBox On Feb 9, 6:37 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com> wrote: > Wonder, what made someone to name the following things?! > > ERROR_SUCCESS <> It's called ERROR_SUCCESS because it's an error code (and therefore must be named ERROR_something) but no error occurred. </> http://blogs.msdn.com/oldnewthing/archive/2004/08/31/223271.aspx > CCheckListBox Whats wrong with this? --- Ajay On 9 Feb 2007 06:21:20 -0800, "Ajay Kalra" <ajay...

Independant Modeless CDialog
Hi, I am having some serious difficulty with a problem of multiple windows in the same application. I use a CDialog as my main window, which is created in the main app call with DoModal, from it however, I wish to create several dialogs that are modeless, each has a taskbar entry (somewhat like MSN messenger) - However, whenever I click on any of these windows the entire job lot pops up, including my origional window. I know in VB that everything was pretty independant, you could switch between windows at your chosing, and only toolbar windows would pop up, thats kind of what I am aft...

How to show "Run as" Dialog from MFC application
Hi, I have a SDI MFC application. I need to do the following: When I run the MFC application for a non-admin user in Windows XP by clicking on the executable, I need the application to pop - up the "Run as following user" dialog. And, if the credentials are right the application thread should run under administrative privileges. In short, I want the behaviour to be same as doing a right click on the .exe and selecting Run As option. Please Help!! Regards, Susanna See if the following link helps you http://tinyurl.com/33l6lt Cheers Check Abdoul ---------------...

CView VS CDialog
Hello, Can i create some CView on CDialog Object ?? How can i do it ?? thanks. "Ahryman40k" <gbaudin2@wanadoo.fr> wrote in message news:bmefmd$3sv$1@news-reader5.wanadoo.fr... > Hello, > > Can i create some CView on CDialog Object ?? > > How can i do it ?? > > thanks. I'm assuming you mean creating a view as a control on a dialog. It can be done with MFC 6.0, but Microsoft almost certainly doesn't support it and you may find it can't be done in a later version of MFC. Your view needs to override OnMouseActivate so that it doesn'...

Integration Manager DLL error
While trying to run any integration I receive this error message. "The destination could not be initialized due to the following problem" "Error loading DLL". I have alreday tried uninstalling and reinstalling integration manger that did not work. I'm a little lost on how to fix this problem any help would be appreciated. Domenic ------=_NextPart_0001_37D35BB5 Content-Type: text/plain Content-Transfer-Encoding: 7bit Domenic, To get around the Error in Loading .DLL error message, you can try to repair your IM installation or even your Dynamics GP installation. ...

Passing data out of a dll
Hi all... I have a dll that needs to pass on some data back to the main program. But I'm not entirely sure how I can accomplish this and still keep the dll free from unnecessary dependencies. I thought of defining a struct inside the dll, and passing back a pointer to it (after the dll filled it up)... but then the main program would need to be made aware of the struct definition too. So then I thought of moving the struct definition into a separate header file and including that in both the main program and the dll. This, although solves the initial problem, would create an indirec...