Program hangs on exit when using wxMultiChoiceDialog with wxSmith

[Miguel Gimenez]

I have used common dialogs with wxSmith before without any problem, but today I have used wxMultiChoiceDialog and the program hanged on exit.

Checking the dialog flow I have noticed that the common dialogs (FileDialog, DirDialog...) are created by wxSmith but they are never destroyed. Adding a call to wxMultiChoiceDialog->Destroy() in the main frame destructor solves the hang issue.

I think wxSmith should call Destroy() of the common dialogs it creates, otherwise we are exposed to hangs and memory leaks.

[ollydbg]

How do you use the dialog? Does wxsmith generate the creating code of a dialog?
For me, I just use wxsmith to generate a dialog header file and implementation file, and all the creating and destroying code are added manually by hand.

[Miguel Gimenez]

If you have a frame (generated with wxSmith) and add a wxMultiChoiceDialog to the frame (using wxSmith again) you end with this:

Frame constructor (some code removed for clarity)

Code Select Expand


    //(*Initialize(FichaFrame)
    Create(parent, wxID_ANY, _("Test"), wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE, "wxID_ANY");
    wxString __wxMultiChoiceDialogChoices_1[3] =
    {
        _("PDF"),
        _("CSV"),
        _("HTML")
    };

    MultiChoiceDialog1 = new wxMultiChoiceDialog(this, _("A"), _("B"), 3, __wxMultiChoiceDialogChoices_1, wxCHOICEDLG_STYLE|wxOK|wxCANCEL|wxCENTRE, wxDefaultPosition);
    //*)


Frame destructor

Code Select Expand


    //(*Destroy(FichaFrame)
    //*)


The wxSmith code in the frame destructor should be

Code Select Expand


    //(*Destroy(FichaFrame)
    MultiChoiceDialog1->Destroy();
    //*)


THe lack of destruction is OK for things like wxButtons and the such, as they are owned and destroyed by containers, but not for common dialogs. FileDialog, DirDialog and others suffer the same problem.

I have been looking in wxSmith's code and there is no provision for filling the destructor part (something like OnBuildDestroyingCode()).

[oBFusCATed]

But this usage of these dialogs isn't really good. They are meant to be used locally and to have very little scope. I don't think it is a job of wxSmith to manage these dialogs.

[BlueHazzard]

Code: [Select]

    //(*Destroy(FichaFrame)
    //*)


The wxSmith code in the frame destructor should be

Code: [Select]

    //(*Destroy(FichaFrame)
    MultiChoiceDialog1->Destroy();
    //*)

the code to construct this is in the pipeline (if this is the correct way to use the dialog is a other question that i can not answer

[sodev]

I'm not familiar with wxSmith but why / how can you add a top-level element inside another top-level element? This shouldn't be possible at all, after all the dialog is not part of the layout of the frame but an individual element by itself.

And like oBFusCATed already said, these modal dialogs are not designed for a longer lifetime, they get created locally on the stack, you call their usually single method that returns a result and then they get deleted by the block scope. And all this happens inside user code and not the layout code created by a gui builder.

[Miguel Gimenez]

The solution may be fixing them (thanks BlueHazzard), removing them if they have no sense or add a note in a "Known issues" section in the documentation. The memory leak is a minor problem, the hang on closing is.

They have little sense in wxSmith, but they are handy for one-frame small utilities. Other items strange in wxSmith are some in the Tools section: wxTimer, wxSingleInstanceChecker, wxStopWatch... In their case there is no problem with destruction, because they are not created in the heap.

[Miguel Gimenez]

Created ticket 845

https://sourceforge.net/p/codeblocks/tickets/845/