Modified & Improved wxWidgets Project Wizard

[TDragon]

Just please make sure that __wxdebug__ is never set unless the user explicitly clicks on it.

Just as an FYI, when using wxWidgets with MSVC, it's almost always correct to define __WXDEBUG__ for a project's debug build and not define it for the release build. This is because of MSVC's debug and non-debug runtime library -- a project that links with the debug runtime requires wxWidgets to have been linked with the debug runtime also, and the same for the non-debug runtime.

[Pecan]

Just please make sure that __wxdebug__ is never set unless the user explicitly clicks on it.

Just as an FYI, when using wxWidgets with MSVC, it's almost always correct to define __WXDEBUG__ for a project's debug build and not define it for the release build. This is because of MSVC's debug and non-debug runtime library -- a project that links with the debug runtime requires wxWidgets to have been linked with the debug runtime also, and the same for the non-debug runtime.

Oh dear. What a mess.... Poor Biplab! What did you get yourself into?

[Biplab]

Yes! It's indeed a mess. Not all the compilers behave similarly. So I kept the Common Minimum Options and left other options at the discretion of users.

Problems will arise with MSVC 7.1 & 8 and as well as BCC. BCC will not accept to compile wx app in Console mode unless some manual hacking is done.

So still in a mess on what to do. I can add another option saying "Don't Add __WXDEBUG__". But that'll mean a number of changes.

[TDragon]

My suggestion: Use an option called "Debug target uses debug wxWidgets libraries", enabled by default for MSVC and disabled by default for GCC. (Using the debug libraries implies including __WXDEBUG__.)

[Biplab]

By default Debug Target uses Debug wx lib with __WXDEBUG__ for all. But if it has to disable it then which library should be set default to for GCC? 

[Pecan]

By default Debug Target uses Debug wx lib with __WXDEBUG__ for all. But if it has to disable it then which library should be set default to for GCC? 

For gcc, NOT using __WXDEBUG__ in a debug target is simply a release target with the -g flag set. ie, just don't append the "d" to any filenames and don't set the -D__WXDEBUG__.

It would also be nice if "Enable all compiler warnings" was set. But I won't quibble over this.

What we're after here is a debuggable CodeBlocks (or any wxwidgets target) with debug symbols linked in, but a wxWidgets with NO debug symbols linked in.

This way, when you're stepping trough CodeBlocks (or any wxwidgets target), you won't accidently step into the wxWidgets can of worms. Accidently stepping into wxWidgets can take a major effort to get out, especially since GDB "stepout" doesn't seem to work.

It also means that the user can debug CodeBlocks (or any wxwidget target) without having to build/load/maintain a debug version of wxWidgets.

Having to tell a new plugin builder that s/he first has to build and deal with a debug version of wxWidgets in order to debug a simple plugin is not a pleasant thought.

[TDragon]

By default Debug Target uses Debug wx lib with __WXDEBUG__ for all. But if it has to disable it then which library should be set default to for GCC? 

The standard, non-debug library (i.e. libwxmsw26u.a for monolithic-unicode).

So if my suggested checkbox is checked, nothing changes: you get a standard debug target linking to the debug wx libs with __WXDEBUG__ defined. If the box isn't checked, the debug target uses the release wx libs and doesn't define __WXDEBUG__ (but still uses -g). Then you just make the box checked by default when using MSVC, and unchecked by default when using GCC.

[Biplab]

First of all my apologies to Pecan and TDragon for this late reply. I got busy with my studies and couldn't touch this.

I have made the following changes. (Screenshot has been removed)

If "Don't use __WXDEBUG__ and Debug wxWidgets lib" is selected, wizard will-

• Not use debug lib of wx
• Will not use __WXDEBUG__

So the generated debug target will have -g option with release wx lib, but release target will remain as usual.

I've selected this option to maintain the flow of wizard. As this is specially available for GCC, this will remain hidden for newcomers.

You'll require just One additional click to activate this feature.

Please post your valuable opinion.

I've not committed the code to svn yet.

[TDragon]

In my valuable opinion ( ) that should work perfectly. (Although I could get extremely nitpicky and say that, according to human interface guidelines, checkboxes should be checked to indicate affirmation and unchecked to indicate negation. But I could hardly care less.)

At any rate, I'd like to know whenever you commit so I can give it another run-through with GCC and VC2005; I haven't actually tried the wizard in quite a while.

[Biplab]

In my valuable opinion ( ) that should work perfectly.

Thanks for ur valuable opinion.

(Although I could get extremely nitpicky and say that, according to human interface guidelines, checkboxes should be checked to indicate affirmation and unchecked to indicate negation. But I could hardly care less.)

Thanks for the point. I'd change it to Use __WXDEBUG__ and Debug wxWidgets lib and keep it unchecked. I hope that would be acceptable.

At any rate, I'd like to know whenever you commit so I can give it another run-through with GCC and VC2005; I haven't actually tried the wizard in quite a while.

I'd PM you and Pecan after I commit.

[Biplab]

Latest Changes:

• Now wizard can setup debug target using Release wxWidgets lib and without __WXDEBUG__. Please remember that this is available only for GCC in Windows.
• Set Target Types option has been renamed to Configure Advanced Options.

To use the new feature do the following. When you get the following screen, check Configure Advanced Options.




You'll be taken to the following page.



By default, the option Use __WXDEBUG__ and Debug wxWidgets lib option is unchecked. Now wizard will not add debug wx libs and __WXDEBUG__ to project.

If you don't want to use this feature but only want to change the target type, then don't forget to check this again.

Thanks to Pecan and TDragon for discussing the necessity of this feature in details.

Changes are in Revision 3610.

[rjmyst3]

Biplab,
 If I were to supply you with a patch that added a "Use wxFormBuilder for GUI Design" checkbox to the wizard and generated the necessary files, what are the chances that you would accept it?

[byo]

Biplab,
 If I were to supply you with a patch that added a "Use wxFormBuilder for GUI Design" checkbox to the wizard and generated the necessary files, what are the chances that you would accept it?

Uhm, same question for wxSmith
Maybe there could be some combo with "Preffered RAD tool" or something simillar?

[RJP Computing]

That would be AWESOME!

[Biplab]

@rjmyst3

Yes I'd accept that if it doesn't break other parts.

I am personally an user of wxFormBuilder. So I would be happy to see that. But there are couple of problems which needs to be addressed.

What is your idea about adding the support? In my opinion we can add the file (wxFB project file) to C::B Project as a dummy one which will not be compiled or linked. It will open externally in wxFB.

wxFB does not support addition of Event Handling at the present moment. So if an user regenerates the UI in wxFB, it can overwrite original source. Though subclassing is an option which is available in wxFB, but it could make the matter complicate for newbies (I could remember my ordials even some time back )

So I need an fair idea of how you want to implement it.


@byo

I've tried only old wxSmith plugin long ago. So I need ur help to add support of this. What I suggest is to add another page (Just like version selection page) where user can select wxSmith or wxFormBuilder or None for GUI development.

IMHO, adding support for wxSmith would be far more easier as it's already integrated. Though I don't use it, I appreciate your hard work involved in that plugin.


@Both

Do you want the wizard to stop generating the sample source and rather use files generated by the GUI builder; or you just want to add a GUI project file so that user can Copy-Paste it (Though this is a bad idea)? As I've said, adding support for wxSmith would be easier in this regard for the first option. One important point to note is the first option would require the wizard to be modified thoroughly and would break few important features.

Regards,

Biplab