Call to SetMenuBar() Results in Segmentation Fault

[doublemax]

Open TIA_Designerframe.wxs and check if the size values are really gone. If not, try to delete them manually (in the file) and recreate the .cpp file ( i don't know how to do that in wxSmith ).

[eranon]

I found the default size checkbox. I have checked it for all tabs in the wxNotebook front panel object. But the segmentation fault persists.

If you checked the "Default size" option about the concerned panel, wxSmith should regenerate the constructor appropriately. I just checked before to write this creating a quick test project through the Codeblocks wizard and everytime I check or uncheck this option, the code is well rewritten (ie. app crashes when not checked and it is well launched when checked). So, the only thing I see doing your code could be not regenerated would be that you removed the wxSmith surrounding tags it uses to locate its own code in your .cpp file.

I mean:

Code: Select all

    //(*Initialize(wxsmith_testFrame)
    The wxSmith code is generated between these tags
    //*)

This said, if you want to recreate the cpp file from scratch as doublemax suggested, you simply have to delete (or rename if you have to retrieve your own code around afterward) it and wxSmith will regenerate it on next build. It should generate a warning like this one below, but the cpp file will be well recreated (unless your eventual code outside of the wxSmith tags, of course).

Code: Select all

||WARNING: Can't read file's timestamp: D:\ELN\ProjNET\FFhLab\Dev\_RD\_sandbox\wxsmith_test\wxsmith_testApp.cpp|

[spflanze]

I found a workaround for this problem. The application runs now.

As doublemax pointed out segmentation fault happens in the frame's constructor where the same sizer is set to two different windows.

Code: Select all

    D1TabBoxSizer = new wxBoxSizer(wxHORIZONTAL);
    D1TabPanel->SetSizer(D1TabBoxSizer);
    SetSizer(D1TabBoxSizer);
    Layout();

SetSizer() is a member function of wxFrame from which the frame's class is derived. I assume it is only the SetSizer() that is a member of wxBoxSizer that should be called, and not the member of wxFrame. So the objective is to create a filter in the frame's class so wxFrame::SetSizer() is not called on objects that have already been passed to wxBoxSizer::SetSizer().

For all sizer objects that are to be filtered I checked the "Is member" checkbox in properties. In the frame's declaration I overrode the wxFrame::SetSizer() member function:

Code: Select all

class TIA_DesignerFrame: public wxFrame
{
    public:

        TIA_DesignerFrame(wxWindow* parent,wxWindowID id = -1);
        virtual ~TIA_DesignerFrame();

			  void SetSizer( wxSizer *  sizer );

The implementation:

Code: Select all

void TIA_DesignerFrame::SetSizer( wxSizer *  sizer )
{ if(	sizer != BoxSizerPanel &&
			sizer != Q1TabBoxSizer &&
			sizer != Q2TabBoxSizer &&
			sizer != D1TabBoxSizer &&
			sizer != A1TabBoxSizer &&
			sizer != FilesFlexGridSizer
	)  wxFrame::SetSizer( sizer );
}

Now I do not have to delete or comment out the troublesome calls to wxFrame::SetSize wxSmith generates in TIA_DesignerFrame 's constructor after every generation.

[doublemax]

No offense, but this is giving me the creeps

[eranon]

Wow! What you do here is a workaround, not a solution. You know, it's as if I knew that a literal string was bad in my source code and that I solve the problem by an automated search & replace in the final executable at post-build step °O° Frankly, solve the issue at wxSmith level; the closest to the root of the issue.

[spflanze]

It is a make do hack that will make it work until wxSmith is fixed. With this hack I need not be concerned about whether the default size checkbox is checked.

The wxSmith surrounding tags are intact. I know enough not to alter them.

Unless you suspect something is corrupt in my files that causes wxSmith to malfunction this will be my solution until the next version of wxSmith comes out.

[eranon]

Yes, I think it should have something wrong in your context because when I switch ON/OFF a default size in the wxSmith I have here (SVN head), the code is well regenerated (while it sounds to be not on your side).

So, in your case, there're two issues : the first one is the one we all see (the one about the need of default size to prevent wrong code), and the second one is only seen by you (the fact the code is not regenerated). If you expect on a fix a day, you have to talk in http://forums.codeblocks.org/, then maybe open an issue report...

[spflanze]

Can a corrupt .wxs file do this?

[eranon]

I don't know the wxSmith's internal, it depends how the file is parsed and the eventual level of corruption. I guess you should see some missing controls or a complete reject on parsing... I would be more inclined to think your .wxs file is right, but something prevent to overwrite it. It's relatively easy to verify: if you change a property through wxSmith, then save the result, do you see the change in the .wxs that you can load in any text editor?