Modified & Improved wxWidgets Project Wizard

[Biplab]

Hi Everybody,

I have modified and improved the wxWidgets Project Wizard. Please note that the modifications are Windows platform specific.

New Features:

• Option to select wxWidgets 2.6.3 or wxWidgets 2.8.0 version libraries (See screenshot below).
• Supports debug, release, static, dynamic, ANSI, Unicode, Monolithic builds of both versions of wxWidgets.
• Added support to MSVC 8 and Borland C++ 5.5.1 compilers.
• Additional compiler flags have been added for MSVC 8. Checks are in place to ensure that they don't come up with MSVC 6 or 7.1
• Option to add additional libraries of wxWidgets if the user is not working with Monolithic build (Partial, see screenshot below).
• Debug target now generates Win32 GUI app instead of Console mode app. It also links against Debug build of wxWidgets.

Changes in Rev 1:

• All the modifications are now restricted to Windows only. Linux or Mac users shall not be affected by Script runtime errors (Please check it once if you are using Linux / Mac). For Linux / Mac platform, the wizard behaviour is old one.
• Wizard now checks for appropriate lib file for Monolithic build and wxbase lib file for non-monolithic builds. Check for setup.h has been removed.
• Deprecated compier option /Og has been removed from MSVC 8.
• $(#wx)/include dir is now added as Resource compiler include dir.
• Richtext library can't be selected if user selects wxWidgets 2.6.3.

Changes in Rev 2:

• Wizard is now more clean. Adds minimum of numbers of libraries to the project depending upon user's choice.
• No Win32 libs are added if DLL build of wx lib is selected. Huge thanks to TDragon for pointing that and Mandrav for explaining the reason. 
• MSVC 8 now support wx lib dynamically linked with C Runtime Library (CRT) for all build configurations of wxWidgets. Statically linked wx lib (for MSVC 8 ) are NOT supported anymore.
• Wizard now generates commands to embed manifest file to generated exe file after linking to load CRT properly during runtime (For MSVC 8 only). So no performance issues with wxString now. But your application will now depend upon msvcrt.dll
• Options to select almost all the individual libs of wxWidgets in non-monolithic mode. (see the following screenshots) Please note the none of the lib from Contrib dir are added. If you need them, you have to add them manually.

Changes in Rev 3:

• New Target Policy have been added to linker
• Supports Pre-compiled headers for BCC 5.5.1 and MSVC 8.
• Wizard CPP files are modified to support PCH.
• "Use the debugging libraries" option have been disabled in Windows part. This option is no longer necessary (See screenshot below).
• DECLARE_EVENT_TABLE(); in main.h file has been changed to DECLARE_EVENT_TABLE() This is necessary to avoid error while compiling with BCC.
• msvcrt.lib is now added as /NODEFAULTLIB in Debug target of MSVC 8 to avoid warning messages in some cases.

Changes in Rev 3.3:

• Missing preprocessor definition, USE_PCH, in project file of BCC has been fixed.
• Preprocessor definition in BCC for Unicode app has been changed to UNICODE from wxUSE_UNICODE as BCC doesn't likes it.
• Now option to select Advanced UI Library will NOT be available if wxWidgets 2.6.x is used

Changes in Rev 4:

• Wizard now sets Appropriate wxWidgets lib order. But do not forget to add any necessary additional wx libs (Jpeg, Tiff, expat or regex) if you are using advanced lib (RichText, AUI, etc); wizard will not add them. Thanks to three_minute_hero for pointing this.
• Now XML and XRC lib can be selected separately.
• Wizard now stops compilation of wx_pch.h in Non-PCH project builds (This is a temporary fix, needs Improvement). Thanks to Ryan for pointing this.
• Wizard supports BCC 5.82 Compiler. You can now build wx app with it.

Changes in Rev 5:

• Supports Microsoft Visual C++ 7.1 Compiler.
• PCH support is activated for MSVC 7.1 compiler.

Changes in Rev 6:

• Added support (partial) for Linux and Mac (Untested). It's now possible to select different wxWidgets version present in Linux system.
• Added option to select Static/Dynamic, ANSI/Unicode build of wxWidgets in Linux.
• Added option to select Application Target Type in Windows (For Advanced users only)
• Wizard now checks the presence of wx configuration, selected for project, precisely in Windows. Expect almost No false warning.
• Couple of minor fixes and code clean-up.

Changes in Rev 7:

• Creation of Empty Project is now possible.
• Wizard now generates customised header/source files. Filenames are generated on the basis of project name.
• Wizard now accepts Author name, email and website to customise header/source files generated by the wizard.
• Wizard now generates resource file in Windows. Default wx icon is used. XP theme support is also enabled using wx.rc file.
• Wizard now remembers following preferences.
  • wxWidgets configuration settings
  • Author details

Wizard page to select wxWidgets Version.


Wizard page to add additional libraries if Monolithic build is not selected. Check the option, in bold, to go the next page.

One point to remember that though there is no Next button, but clicking on Finish button will move to next page (if the Add more wxWidgets libraries is selected).


If you need more, then add them here.

Tested with:

• wxWidgets compiled with GCC (MinGW Build) as Release-Dynamic-Monolithic-Unicode build.
• wxWidgets compiled with Borland C++ 5.5.1 as Debug, Release, Static, Dynamic build
• wxWidgets compiled with MSVC 7.1, 8 as Debug, Release, Static, Dynamic and Unicode build. Dynamic linking of C Runtime Libraries have been used.

Known issues:

• Does not support MSVC 6.
• PCH support does not work with MSVC 6
• PCH support needs improvement.

"Use the debugging libraries" option is disabled (For Windows only).

I am attaching the modified files. Please take backup of old files and replace the new files in their place. The files shall be placed to <Code::Blocks Dir>\share\CodeBlocks\templates\wizard\wxwidgets folder.

Please test it and give your feedback and suggestions.  Please login to download the attachment. Also download the latest revision.

Latest Release: Revision 7

[attachment deleted by admin]

[Commodore64]

It looks like an excellent improvement!
Thank you  and merry Christmas!

[Biplab]

Thanks for your encouraging words.

Please test the wizard and post your comments, suggestions. I didn't submit patch to Berlios as I could not test it with all possible configurations. After I get good feedback I'll upload patch to Berlios.

[TDragon]

Why, exactly, does your version disable the debug version under Windows? I use it with MinGW (and VC8, though not through C::B).

[Biplab]

I didn't disable the Debug target in Windows and it's there.

Earlier the wizard generated Debug target as Console mode application and the Debug target could be linked againts Debug or Release build of wxWidgets. E.g., let's say you've selected DLL, release lib of wx with earlier wizard, it used to create two targets -

• Debug target - Links as Console mode app with Release lib of wx
• Release target - Links as Win32 GUI mode app with Release lib of wx

With earlier wizard, Debug target didn't mean that you are linking against Debug lib of wx, rather to link against Debug lib of wx you had to select the option "Use the debugging libraries".

The modified wizard creates the target in the following way -

• Debug target - links against Debug lib of wx
• Release target - links against Release lib of wx

Thus the option, use the debugging libraries, have been disabled internally for Windows as it has little significance.

I hope I've cleared your doubts.

Also please give this wizard a try, this works nicely with MSVC 8. 

[TDragon]

Aside from throwing in a few libraries I don't really need (jpeg, tiff, etc.), this version works admirably well. My apologies for the earlier confusion.

Tested:
GCC, Debug, Shared, Multi-Lib, Non-Unicode
GCC, Release, Shared, Multi-Lib, Non-Unicode

Kudos!

[Biplab]

Aside from throwing in a few libraries I don't really need (jpeg, tiff, etc.), this version works admirably well. My apologies for the earlier confusion.

Tested:
GCC, Debug, Shared, Multi-Lib, Non-Unicode
GCC, Release, Shared, Multi-Lib, Non-Unicode

Kudos!

Thanks for your reply. 

jpeg, tiff libs are sometimes necessary for proper linking of application written in wxWidgets. Therefore I have added most of the libraries to avoid flood of errors. Sometimes a number of errors are generated if you don't add them.

Unfortunately, if some libraries or some other options are added to Global scope in the Code::Blocks project file, they do not show up in the Build Options dialog. Thus you didn't find other libs. If you open the .cbp file with a Text editor, you'll find a number of win32 specific libraries have been added. Though not all of the libraries are necessary to compile a simple application but they were necessary to support other compilers.

Also thanks for testing the wizard. 

[TDragon]

jpeg, tiff libs are sometimes necessary for proper linking of application written in wxWidgets. Therefore I have added most of the libraries to avoid flood of errors. Sometimes a number of errors are generated if you don't add them.

Using GCC, wxbase28, wxmsw28, and wxmsw28_adv are all that I need to build and run one of my wxWidgets projects using the wxWidgets DLLs. None of the additional libraries from the wxWidgets lib directory appear to be necessary, nor do any of the Win32 libs. Conversely, most if not all of these additional libraries are necessary when statically linking wxWidgets.

If this is not the case for compilers other than GCC, then I would expect a well-designed wizard to distinguish among the various compilers and set the options accordingly.

[Biplab]

jpeg, tiff libs are sometimes necessary for proper linking of application written in wxWidgets. Therefore I have added most of the libraries to avoid flood of errors. Sometimes a number of errors are generated if you don't add them.

Using GCC, wxbase28, wxmsw28, and wxmsw28_adv are all that I need to build and run one of my wxWidgets projects using the wxWidgets DLLs. None of the additional libraries from the wxWidgets lib directory appear to be necessary, nor do any of the Win32 libs. Conversely, most if not all of these additional libraries are necessary when statically linking wxWidgets.

To build an Win32 gui app, you need several libraries from Windows SDK. wxWidgets apps can't just be compiled only with wxbase, wxmswcore and wxmsw28_adv. Additional libraries are added by linkers. Try equivalent linker option of /NODEFAULTLIB (exists in MSVC and I don't know whether there are any equivalent option in GCC) in gcc and see which libraries it asks.

Unfortunately, if some libraries or some other options are added to Global scope in the Code::Blocks project file, they do not show up in the Build Options dialog.

I mentioned it to inform you that you may not see the couple of libraries that are added to your wxWidgets project even with the old wizard. These libraries are - comctl32, gdi32, ole32, oleaut32, uuid but you will not see them until you open the Code::Blocks Project file with Notepad. These are essential libraries and work for the minimal app. If the application uses any File Open/Save or any other common dialogs, you need to add comdlg32, for odbc related app add odbc32, for any network related calls you need wsock32, so on and so forth. So better add most of the common libraries otherwise user has to add them manually.

If this is not the case for compilers other than GCC, then I would expect a well-designed wizard to distinguish among the various compilers and set the options accordingly.

The wizard first adds common essential libraries and then adds compiler specific libraries, if any, in the project file. E.g., you need to add import32.lib, cw32mti.lib if you are using Borland C++ 5.5.1 compiler. You won't find them if you are using any other compilers.

[TDragon]

Using GCC, wxbase28, wxmsw28, and wxmsw28_adv are all that I need to build and run one of my wxWidgets projects using the wxWidgets DLLs. None of the additional libraries from the wxWidgets lib directory appear to be necessary, nor do any of the Win32 libs.

"Read my lips." If this were not the case, I'd expect the following command line, copied and pasted directly from the Build log, to kick up a few errors:

Code

mingw32-g++.exe -LE:\Libraries\wxMSW-2.8.0\lib\gcc_dll  -o test.exe main.o app.o    -lwxmsw28d_core -lwxbase28d -lwxmsw28d_adv

But there are none, and the resulting executable works without problems. So also does the more complex project I alluded to earlier, which has many more files' worth of code. You might notice that MinGW's "-mwindows" option is unnecessary to successfully build and run it.

Try equivalent linker option of /NODEFAULTLIB (exists in MSVC and I don't know whether there are any equivalent option in GCC) in gcc and see which libraries it asks.

The option, in case you're curious, is "-nodefaultlibs". It brings in a host of missing references to some objects in the CRT, C++ operators new and delete, and various objects relating to structured exceptions. None are present in your extraneous Win32 libraries.

I mentioned it to inform you that you may not see the couple of libraries that are added to your wxWidgets project even with the old wizard. These libraries are - comctl32, gdi32, ole32, oleaut32, uuid but you will not see them until you open the Code::Blocks Project file with Notepad.

The Build options visible in C::B for each of my wxWidgets projects mirror the options in the .cbp file when viewed in Notepad. The wxWidgets libraries appear in the Debug or Release build options, and the Win32 libraries in the overarching project build options. Modifying the libraries in either place and saving the project results in the expected changes to both the project file and the resulting command lines during the build process.

Some further explanation:
If you think about it, that's the way the wxWidgets DLLs should work. wxWidgets presents an entirely new interface to its users that completely hides Win32, such that no Win32 function calls exist in the wxWidgets headers. If your app's code contains no Win32 function calls, it has no dependencies on the Win32 libraries; every Win32 function call happens within the code in the wxWidgets DLL, and the resulting dependencies are resolved when the DLL is linked rather than when your app is.

[Biplab]

Using GCC, wxbase28, wxmsw28, and wxmsw28_adv are all that I need to build and run one of my wxWidgets projects using the wxWidgets DLLs. None of the additional libraries from the wxWidgets lib directory appear to be necessary, nor do any of the Win32 libs.

"Read my lips." If this were not the case, I'd expect the following command line, copied and pasted directly from the Build log, to kick up a few errors:

Code

mingw32-g++.exe -LE:\Libraries\wxMSW-2.8.0\lib\gcc_dll  -o test.exe main.o app.o    -lwxmsw28d_core -lwxbase28d -lwxmsw28d_adv

But there are none, and the resulting executable works without problems. So also does the more complex project I alluded to earlier, which has many more files' worth of code. You might notice that MinGW's "-mwindows" option is unnecessary to successfully build and run it.

I've tested this with GCC and Borland. The app compiles even if you don't add a single extra Win32 SDK lib. But with Borland you need to add wxpng and wxzlib libraries in order to compile successfully. But I found a lot of errors while compiling with MSVC 8. Some of them are as follows --

:: === TestWX, Debug ===
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__GdiFlush@0 referenced in function "public: virtual void __thiscall wxWindow::Update(void)" (?Update@wxWindow@@UAEXXZ)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__DragAcceptFiles@8 referenced in function "public: virtual void __thiscall wxWindow::DragAcceptFiles(bool)" (?DragAcceptFiles@wxWindow@@UAEX_N@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__GetTextMetricsA@8 referenced in function "public: virtual void __thiscall wxWindow::GetTextExtent(class wxString const &,int *,int *,int *,int *,class wxFont const *)const " (?GetTextExtent@wxWindow@@UBEXABVwxString@@PAH111PBVwxFont@@@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__GetTextExtentPoint32A@16 referenced in function "public: virtual void __thiscall wxWindow::GetTextExtent(class wxString const &,int *,int *,int *,int *,class wxFont const *)const " (?GetTextExtent@wxWindow@@UBEXABVwxString@@PAH111PBVwxFont@@@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__DragQueryPoint@8 referenced in function "public: bool __thiscall wxWindow::HandleDropFiles(unsigned int)" (?HandleDropFiles@wxWindow@@QAE_NI@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__DragFinish@4 referenced in function "public: bool __thiscall wxWindow::HandleDropFiles(unsigned int)" (?HandleDropFiles@wxWindow@@QAE_NI@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__DragQueryFileA@16 referenced in function "public: bool __thiscall wxWindow::HandleDropFiles(unsigned int)" (?HandleDropFiles@wxWindow@@QAE_NI@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__RealizePalette@4 referenced in function "public: bool __thiscall wxWindow::HandlePaletteChanged(void *)" (?HandlePaletteChanged@wxWindow@@QAE_NPAX@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__SelectPalette@12 referenced in function "public: bool __thiscall wxWindow::HandlePaletteChanged(void *)" (?HandlePaletteChanged@wxWindow@@QAE_NPAX@Z)
wxmsw28d_core.lib(window.obj):: error LNK2019: unresolved external symbol __imp__CreateRectRgn@16 referenced in function "public: bool __thiscall wxWindow::HandlePaint(void)" (?HandlePaint@wxWindow@@QAE_NXZ)
wxmsw28d_core.lib(checklst.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(listctrl.obj):: error LNK2019: unresolved external symbol __imp__SelectObject@8 referenced in function "public: virtual __thiscall wxCommandEvent::~wxCommandEvent(void)" (??1wxCommandEvent@@UAE@XZ)
wxmsw28d_core.lib(dib.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(clipbrd.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(dcprint.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(bmpbuttn.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(ownerdrw.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(notebook.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(treectrl.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(tooltip.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(button.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(dcmemory.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(listbox.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(window.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(tbar95.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(bitmap.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(dc.obj):: error LNK2001: unresolved external symbol __imp__SelectObject@8
wxmsw28d_core.lib(toplevel.obj):: error LNK2019: unresolved external symbol __imp__OffsetRgn@12 referenced in function "public: virtual bool __thiscall wxTopLevelWindowMSW::SetShape(class wxRegion const &)" (?SetShape@wxTopLevelWindowMSW@@UAE_NABVwxRegion@@@Z)
wxmsw28d_core.lib(region.obj):: error LNK2001: unresolved external symbol __imp__OffsetRgn@12
wxmsw28d_core.lib(statbox.obj):: error LNK2001: unresolved external symbol __imp__OffsetRgn@12
wxmsw28d_core.lib(toplevel.obj):: error LNK2019: unresolved external symbol __imp__ExtCreateRegion@12 referenced in function "public: virtual bool __thiscall wxTopLevelWindowMSW::SetShape(class wxRegion const &)" (?SetShape@wxTopLevelWindowMSW@@UAE_NABVwxRegion@@@Z)
wxmsw28d_core.lib(region.obj):: error LNK2001: unresolved external symbol __imp__ExtCreateRegion@12
wxmsw28d_core.lib(toplevel.obj):: error LNK2019: unresolved external symbol __imp__GetRegionData@12 referenced in function "public: virtual bool __thiscall wxTopLevelWindowMSW::SetShape(class wxRegion const &)" (?SetShape@wxTopLevelWindowMSW@@UAE_NABVwxRegion@@@Z)
wxmsw28d_core.lib(app.obj):: error LNK2019: unresolved external symbol __imp__InitCommonControls@0 referenced in function "public: virtual bool __thiscall wxApp::Initialize(int &,char * *)" (?Initialize@wxApp@@UAE_NAAHPAPAD@Z)
wxmsw28d_core.lib(app.obj):: error LNK2019: unresolved external symbol __imp__OleInitialize@4 referenced in function "bool __cdecl wxOleInitialize(void)" (?wxOleInitialize@@YA_NXZ)
wxmsw28d_core.lib(clipbrd.obj):: error LNK2001: unresolved external symbol __imp__OleInitialize@4
wxmsw28d_core.lib(app.obj):: error LNK2019: unresolved external symbol __imp__OleUninitialize@0 referenced in function "void __cdecl wxOleUninitialize(void)" (?wxOleUninitialize@@YAXXZ)
:: More errors follow but not being shown.
:: Edit the max errors limit in compiler options...
:: === Build finished: 50 errors, 0 warnings ===

To solve this I started adding Win32 libraries, one by one. At last the addition of following libraries solved the problem.

winmm.lib, rpcrt4.lib, kernel32.lib, user32.lib, gdi32.lib, ole32.lib, oleaut32.lib, comctl32.lib, comdlg32.lib, uuid.lib, advapi32.lib, shell32.lib

But I don't know why the number of libraries required varies with different compilers? wx Gurus, please shed more light on this.

But as long as I don't know why this is happening, I'll follow the safer route. It's better to have peaceful night rather than breaking one's head over huge number of cryptic error messages.

Code::Blocks team had added few libraries, and I've added few more so that I don't get any error messages and I don't see any point of removing them all, as long as it works with all compilers. 

[bnilsson]

Just for your information,
applying your new script gave me the script error message seen below.
I selected wxWidgets 2.6.x, no extra options.


[attachment deleted by admin]

[Biplab]

Just for your information,
applying your new script gave me the script error message seen below.
I selected wxWidgets 2.6.x, no extra options.

I am very sorry, I may have missed to inform that the modifications are Windows specific.  :oops:  I would rather disable it for other platforms for the time being. I have no idea about Mac/Linux programming, thus I didn't modify them.

You got that script error due to some uninitialized variables, I'll look for that error. It would be of great help if someone modifies the script for Linux/Mac. 

Update:
Thanks for posting that bug. It was due to some uninitialised variables of Windows part coming to Unix part of the script. I have now modified the code to restrict all the modification to Windows platform only. Please check it once and post if you're getting any errors. Also my apologies for not mentioning the platform in my original post.

[Biplab]

Hi,

I've uploaded new wizard file. Modifications / Improvements are-

• All the modifications are now restricted to Windows only. Linux or Mac users shall not be affected by Script runtime errors (Please check it once if you are using Linux / Mac). For Linux / Mac platform, the wizard behaviour is old one.
• Wizard now checks for appropriate lib file for Monolithic build and wxbase lib file for non-monolithic builds. Check for setup.h has been removed.
• Deprecated compier option /Og has been removed from MSVC 8.
• $(#wx)/include dir is now added as Resource compiler include dir.
• Richtext library can't be selected if user selects wxWidgets 2.6.3.

P.S. - I don't have any experience with Linux. It would be nice if someone modifies the Unix part of the wizard.    I think couple of changes to the directory of wx-config for each version should do the job. But I don't know how to do that. 

[TDragon]

I've tested this with GCC and Borland. The app compiles even if you don't add a single extra Win32 SDK lib. But with Borland you need to add wxpng and wxzlib libraries in order to compile successfully. But I found a lot of errors while compiling with MSVC 8.
...
Code::Blocks team had added few libraries, and I've added few more so that I don't get any error messages and I don't see any point of removing them all, as long as it works with all compilers. 

If this is not the case for compilers other than GCC, then I would expect a well-designed wizard to distinguish among the various compilers and set the options accordingly.

The point of removing the unnecessary libraries is to provide a cleaner, more polished, more professional product. Sure, everything works as it is right now; it's an improvement over the current wizard, and so I congratulate you. As I said originally: aside from throwing in a few libraries I don't need, this version works admirably well.