Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

wxAuiManager preview issue under wxSmith cause C::B can't exit correctly

<< < (2/6) > >>

ollydbg:

--- Quote from: ollydbg on February 12, 2019, 12:21:02 am ---...
There is a UnInit() function call in the preview wxAuiManager derived object: in file: src\plugins\contrib\wxSmithAui\wxAuiManager\wxSmithAuiManager.h

--- Code: ---#ifndef WXSMITHAUIMANAGER_H
#define WXSMITHAUIMANAGER_H

#include <wx/aui/aui.h>
#include <wx/wx.h>
#include <wx/event.h>

#include <prep.h>

class wxSmithAuiManager : public wxAuiManager
{
    public:
        wxSmithAuiManager(wxWindow* managed_wnd = NULL, unsigned int flags = wxAUI_MGR_DEFAULT)
            : wxAuiManager(managed_wnd, flags)
        {
            Connect(wxEVT_DESTROY,(wxObjectEventFunction)&wxSmithAuiManager::OnDestroy);
        }

        virtual ~wxSmithAuiManager() {}

        void OnDestroy(cb_unused wxWindowDestroyEvent& event)
        {
            UnInit();
        }
    protected:
    private:
};

#endif // WXSMITHAUIMANAGER_H

--- End code ---

So, it will be called when the preview window closed?

--- End quote ---

Oh, bad/good news, I just set a breakpoint in the  UnInit(); line, and When I close debugee C::B, this line does not reached. and debugee C::B now go to endless wait status. So my guess is that why this function call is missing here?

EDIT:
The UnInit() is called after I add one page in the wxAuiManager. When there is no items controlled by wxAuiManager, it is not called.(in the wxsmith preview, wxAuiManager object only constructed when there is at least one item inside it)

ollydbg:
Good news, I think I have find the reason of this issue.

With this patch, I can avoid the hang process when C::B exits. (especially follow my 5 steps in my first post in this thread)

under function: bool wxsAuiManager::OnCanAddToParent(wxsParent* Parent,bool ShowMessage), it need to test whether a wxAuiManager can be child of a Parent window.

--- Code: --- src/plugins/contrib/wxSmithAui/wxAuiManager/wxsAuiManager.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/plugins/contrib/wxSmithAui/wxAuiManager/wxsAuiManager.cpp b/src/plugins/contrib/wxSmithAui/wxAuiManager/wxsAuiManager.cpp
index bbd3d967..60735822 100644
--- a/src/plugins/contrib/wxSmithAui/wxAuiManager/wxsAuiManager.cpp
+++ b/src/plugins/contrib/wxSmithAui/wxAuiManager/wxsAuiManager.cpp
@@ -640,14 +640,14 @@ bool wxsAuiManager::OnCanAddToParent(wxsParent* Parent,bool ShowMessage)
             wxMessageBox(_("wxAuiManager can't be added to a sizer. Add panels first."));
         return false;
     }
-
+#if 0
     if ( !wxDynamicCast(Parent->BuildPreview(new wxFrame(0,-1,wxEmptyString),0),wxWindow) )
     {
         if ( ShowMessage )
             wxMessageBox(_("wxAuiManager can only be added to a wxWindow descendant."));
         return false;
     }
-
+#endif // 0
     return wxsParent::OnCanAddToParent(Parent,ShowMessage);
 }
 


--- End code ---

I'm really don't know what does this code means?

--- Code: ---new wxFrame(0,-1,wxEmptyString)

--- End code ---
This means we allocate a wxFrame under the desktop? The first argument is 0 means the desktop?

I see there are three places which use "new wxFrame(0,...)" in our C::B's source code, and they all exists under the folder:
two places in src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.cpp
one place in src\plugins\contrib\wxSmithAui\wxAuiToolBar\wxsAuiToolBar.cpp

I guess this usage of create a wxFrame is wrong, do you have any ideas how to fix this issue? Thanks.

sodev:
The first argument is actually a pointer and passing a nullptr means to create frame without parent which is fully independend.

I think the reason for CodeBlocks to not close is that no one ever destroys these temporary frames (unless that BuildPreview method does it internally) and the "dangling" frames keep wxWidgets alive.

ollydbg:

--- Quote from: sodev on February 12, 2019, 05:45:33 pm ---The first argument is actually a pointer and passing a nullptr means to create frame without parent which is fully independend.

I think the reason for CodeBlocks to not close is that no one ever destroys these temporary frames (unless that BuildPreview method does it internally) and the "dangling" frames keep wxWidgets alive.

--- End quote ---
Thanks for the explanation. Now, I will try to call the Destroy() function of the frame objects when this function exits. (Documents are here: https://docs.wxwidgets.org/3.1/overview_windowdeletion.html)

ollydbg:
I change the code like below:


--- Code: ---    wxFrame * tempFrame = new wxFrame(0,-1,wxEmptyString);
    if ( !wxDynamicCast(Parent->BuildPreview(tempFrame,0),wxWindow) )
    {
        if ( ShowMessage )
            wxMessageBox(_("wxAuiManager can only be added to a wxWindow descendant."));
        tempFrame->Destroy();
        return false;
    }
    tempFrame->Destroy();

--- End code ---

It looks like this code does not make C::B endless wait on exit. :)

I will change the other "dangling" frame places in wxAui related code in wxsmith.

Navigation

[0] Message Index

[#] Next page

[*] Previous page