#161 "simple application start code to C++ code generator" breaks projects with existing app and/or multiple wxglade frames

[Beuc]

Hi,

I'm using wxglade for the FreeDink DFArc front-end (code freely browsable at http://git.savannah.gnu.org/cgit/freedink/dfarc.git/tree/ ) and I can't compile the project anymore because:

• wxglade now adds a IMPLEMENT_APP(MyApp) which conflicts with the project's IMPLEMENT_APP(DFArcApp)

• wxglade adds a MyApp::OnInit() function which conflicts with other wxglade frames generated.

Short of sed-ing the wxglade output there's no way to work-around this.

How about making this wxglade application stanza optionnal and non-default?

[Carsten Grohmann]

Hi Sylvian,

it looks like the behaviour of wxGlade is wrong. Regarding the documentation:

wxGlade is able to extent the created source for by a code sequence to create and start an instance of projects “Top window”.
In case “Name” and “Class” are set, a detailed start code with a derived class of wxApp will be created. If just “Name” is given, a simplified start code will be generated.

the startup code should be created only if "Name" or "Name" and "Class" are given. During my tests the startup code will be generated always - even if "Name" and "Class" are not set.
I'll fix this bug.

Regards,
Carsten

[Beuc]

Hi,

The problem seems to come from this commit:
https://bitbucket.org/agriggio/wxglade/commits/8c4d1d553680abde168b24b1fed051e99a73880d

The attached patch fixes it :)

(Note that, unlike in the documentation, the previous and current tests are applied on top_win+klass, not name+klass.
My project has no name nor klass, but it does have a top_win:)

{u'class': '',
 u'encoding': 'UTF-8',
 u'for_version': '2.6',
 u'header_extension': '.h',
 u'indent_amount': '4',
 u'indent_symbol': 'space',
 u'is_template': '0',
 u'language': 'C++',
 u'name': '',
 u'option': False,
 u'overwrite': '1',
 u'path': 'Options_Base.cpp',
 u'source_extension': '.cpp',
 u'top_window': 'dialog_1',
 u'use_gettext': '1',
 u'use_new_namespace': '1'}

[Carsten Grohmann]

Hi Beuc,

the bug is fixed in the revision 1414:7a070963581f as well as the next official release. The documentation about the application start code has been updated too (1415:5ecf9c2d7abb).

Thank you for reporting this bug.

Regards,
Carsten