Modified & Improved wxWidgets Project Wizard

[RJP Computing]

@rjmyst3
...
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 )
...

wxFormBuilder does support event handlers now as well as having a wizard to generate your inherited class. These are in in wxFormBuilder v3.0+

[byo]

@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.

To integate wxSmith into current wizard, two things have to be done:

• Sources need few changes - this could be handled by [IF ...] macros so I guess there won't be a problem with it
• wxSmith must be notified about new project and must create some internal bindings. I thought about adding few functions responsible for this task and add them to squirrel so script could call them.

Of course this is my first idea

Regards
   BYO

[rjmyst3]

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.

This should work.

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 )

The files generated by wxFB are not meant to be edited at all. The intended approach is that users create a class which inherits from the class that wxFB generates. The newest version of wxFB will create this class for the user, upon their request, so it should be easier for new users to get started. The newest version will also generate event handlers.

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.

I think we should create the sample with the GUI builder and use those files.

So, to sum up for wxFB, the wizard would generate the wxFB project file, the wxFB generated files, and the user's files which inherit from the generated classes.

[TDragon]

The wizard works quite well and has progressed quite a bit. There are only two things of note:
1. wxpng[d] and wxzlib[d] were added unnecessarily to both my GCC and VC2005 projects. (shared, multi-lib, non-unicode)
2. The tooltip text for the new checkbox says "This is available for GCC only", implying that compilers other than GCC would not be able to use the debug libs.

Keep up the good work!

[Biplab]

wxFormBuilder does support event handlers now as well as having a wizard to generate your inherited class. These are in in wxFormBuilder v3.0+

I think I have missed it. I have compiled the recent svn build few days back. But didn't try using the event handling.

To integate wxSmith into current wizard, two things have to be done:

• Sources need few changes - this could be handled by [IF ...] macros so I guess there won't be a problem with it
• wxSmith must be notified about new project and must create some internal bindings. I thought about adding few functions responsible for this task and add them to squirrel so script could call them.

• First one is easy. This code is available in cbplugin wizard (Handling [IF] macros) and I need to copy-paste that
• Second one I didn't understand. Please explain me a little bit.

By the way I'll try wxSmith to understand it.

This should work.

Then this can be done easily.

The files generated by wxFB are not meant to be edited at all. The intended approach is that users create a class which inherits from the class that wxFB generates. The newest version of wxFB will create this class for the user, upon their request, so it should be easier for new users to get started. The newest version will also generate event handlers.

Ok, then it can be tackled in following way.

This is when user does not want any GUI builder.

Code

#include "TestApp.h"

class TestFrame: public wxFrame

This will be when user is using wxFB.

Code

#include "TestApp.h"
#include "TestFrameGUI.h"

class TestFrame: public TestFrameGUI

where TestFrameGUI class will be generated by wxFB.

I hope for wxSmith the changes will be similar.

1. wxpng[d] and wxzlib[d] were added unnecessarily to both my GCC and VC2005 projects. (shared, multi-lib, non-unicode)
2. The tooltip text for the new checkbox says "This is available for GCC only", implying that compilers other than GCC would not be able to use the debug libs.

1. I checked that and I found that it works without them, too. I'll not make any further changes to this as this minimum config works fine with static and dll libs. Please don't misunderstand me, but changing this means I need to change the last two panels and as well as the script code itself.
2. I didn't add this to other compilers as there could be problems during linking. At least VC will not accept it. But surely, if it works with other compilers, please inform me. I'll update the wizard.

Regards,

Biplab

[rjmyst3]

Ok, then it can be tackled in following way.

This is when user does not want any GUI builder.

Code

#include "TestApp.h"

class TestFrame: public wxFrame

This will be when user is using wxFB.

Code

#include "TestApp.h"
#include "TestFrameGUI.h"

class TestFrame: public TestFrameGUI

where TestFrameGUI class will be generated by wxFB.

Sounds Perfect! 

[TDragon]

2. I didn't add this to other compilers as there could be problems during linking. At least VC will not accept it. But surely, if it works with other compilers, please inform me. I'll update the wizard.

What I'm saying is that your description is misleading. Saying that an option called "Use __WXDEBUG__ and Debug wxWidgets lib" is available for GCC only implies that non-GCC compilers can't use the debug wxWidgets lib -- which is obvioulsy wrong, since the wizard correctly generated a debug target for VC2005 using the debug libs. You just need to reword things.

[Biplab]

Yes, TDragon I noticed that discrepancy after my commit. Actually in the code there is check so that it does not affect any other compilers. Somehow missed to change the text.

I'll change that in next commit.

[byo]

• First one is easy. This code is available in cbplugin wizard (Handling [IF] macros) and I need to copy-paste that
• Second one I didn't understand. Please explain me a little bit.

By the way I'll try wxSmith to understand it.

Ok, I've modified result of wxWidgets wizard little bit to support wxSmith and whole project is in attachment. I've also tried to change files right in wizard's files, but this may be useless since some changes to these files are required when using wxFormBuilder too. If I could make a suggestion, I propose adding these three macros:

• [IF NORMAL]
• [IF WXFORMBUILDER]
• [IF WXSMITH]

Then it would be really easy to modify template files to use one of three schemes.
wxSmith also require one more file (included as wxsmith/wxwizardframe.wxs in attachment), but that should be really easy

About this second 'thing' - wxSmith adds some extensions to C::B projects - each resource is mapped to source/header files and to .wxs file (containing resource's structure or some required extra stuff). Usually these bindings are read from cbp file using C::B's extensions support . But when project is generated from wizard, there's no way to support it. So the first solution I've found is to add special wxSmith-related function to squirrel (and thus allowing them in wizards), which would notice wxSmith about new project and would let it create proper bindings. This function would be enough to properly add full wxSmith support for project.

Regards
  BYO

[attachment deleted by admin]

[Biplab]

Thanks Byo for the code. I'll go through it.

Actually Today I tried wxSmith again to understand it. But could not post as there was some problem during posting. I've created the following page. Please have a look at it.



My idea is also similar of using macros. Already it's in use in one place. While you add the support to add extension to project file, I would start working with basic templates of wxSmith and as well as wxFormBuilder.

Regards,

Biplab

[byo]

Thanks Byo for the code. I'll go through it.

Actually Today I tried wxSmith again to understand it. But could not post as there was some problem during posting. I've created the following page. Please have a look at it.



My idea is also similar of using macros. Already it's in use in one place. While you add the support to add extension to project file, I would start working with basic templates of wxSmith and as well as wxFormBuilder.

Regards,

Biplab

Looks promising

But there may be some problem when using wxSmith's extension - what will happen when wxSmith plugin is not loaded and there's no extra function registered? I hope that squirrel won't fail and that there's a way to check if function is declared.
Making wxWidgets wizard useless only because wxSmith plugin is not loaded sound really badly

BYO

[Biplab]

Hi All,

Here is an update. The wizard code has been modified to enable support for wxFormBuilder + wxFrame based app. The wizard works fine in generating the files.

But I'm facing couple of problems. Files can be added to a Project by the Wizard in two ways.

• Show C::B a folder and it will copy the contents without processing them.
• Give C::B file name and contents and it'll add them.

Problem with the first method is that it doesn't parse the files. So customisations of files are not possible.

Problem with the second method is that you can parse files, but AFAIK it can't add files with unrecognised extensions. The wxFormBuilder (wxFB) project file extension is unrecognised by C::B and therefore it is not adding to project after parsing it.

There is another problem with the second method to parse wxFB project file. Pre-processor definition to enable PCH support can't be customised. If I add the wxFB project file with/without parsing, it is going to break the PCH support.

Following piece of code will make my point clear. An example of wxFB generated code is as follows. wxFB uses WX_GCH whereas the project will use USE_PCH.

Code

#ifdef WX_GCH
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endif

I have decided to go with first method for the time being. But the PCH support will remain broken for wxFB generated code. Though PCH support should work with remaining part of the project.

@rjmyst3
Is it possible to add customisation of this Pre-processor directive in wxFB project file? I just want to change the Pre-processor directive to USE_PCH and want wxFB to use this while regenerating the source. I don't think this would be quite difficult to implement.

@Mandrav
Is there any better alternative to Second method? A link to help would be sufficient.

@byo
I'll implement wxSmith after I fix initial problems. But I have one request. Can you please provide me with two project files, one for Dialog based and one for Frame based? Please include wxs file, cpp and header files.

Regards,

Biplab

Edit 1: Fixed a Typo.

[mandrav]

Problem with the second method is that you can parse files, but AFAIK it can't add files with unrecognised extensions. The wxFormBuilder (wxFB) project file extension is unrecognised by C::B and therefore it is not adding to project after parsing it.

Where did you get that from? You can add whatever kinds of files you want in a project. It's only checking the extensions to decide if each file needs to be built/linked or not.
Give me more info on this. Either you did something wrong or you discovered a bug which we 'll fix.

There is another problem with the second method. Pre-processor definition to enable PCH support can't be customised. If I add the wxFB project file with/without parsing, it is going to break the PCH support.

How come? Why can't you use WX_GCH instead of USE_PCH?

[Biplab]

Where did you get that from? You can add whatever kinds of files you want in a project. It's only checking the extensions to decide if each file needs to be built/linked or not.
Give me more info on this. Either you did something wrong or you discovered a bug which we 'll fix.

I didn't get it from SDK manual. I found that the script is adding additional *.cpp  or *.h files but not adding the *.fbp file. I checked it with ShowInfo() to see whether the parsing is being done or not. I found the parsing is done but it is not adding the file. Later I checked the Debug Log and I found C::B is complaining.

[17:53:14.125]: Add project Test in parsing queue
[17:53:14.218]: Project's base path: C:\Projects\Test\
[17:53:14.218]: Project's common toplevel path: C:\Projects\Test\
[17:53:14.296]: Generated file C:\Projects\Test\TestApp.h
[17:53:14.312]: Generated file C:\Projects\Test\TestApp.cpp
[17:53:14.328]: Generated file C:\Projects\Test\TestMain.h
[17:53:14.359]: Generated file C:\Projects\Test\TestMain.cpp
[17:53:14.375]: Generated file C:\Projects\Test\Test_pch.h
[17:53:14.390]: Generated file C:\Projects\Test\TestGUIFrame.h
[17:53:14.406]: Generated file C:\Projects\Test\TestGUIFrame.cpp
[17:53:14.406]: Attempt to generate a file with forbidden extension!
File: TestGUIFrame.fbp

I'm posting a part of the script for your information.

Code

function GetGeneratedFile(file_index)
{
    if (!IsEmpty)
	{
		local ProjectName = Wizard.GetProjectName();
		if (file_index == 0)
			return ProjectName + _T("App.h") + _T(";") + GenerateHeader(file_index);
		else if (file_index == 1)
	        return ProjectName + _T("App.cpp") + _T(";") + GenerateSource(file_index);
		else if (file_index == 2)
	        return ProjectName + _T("Main.h") + _T(";") + GenerateHeader(file_index);
		else if (file_index == 3)
			return ProjectName + _T("Main.cpp") + _T(";") + GenerateSource(file_index);
		else if (file_index == 4)
		{
			if (WantPCH)
				return ProjectName + _T("_pch.h") + _T(";") + GenerateHeader(file_index); // PCH file
			else
			{
				if (GuiBuilder == 0)
					return _T(""); // Stop Here.
				else if (GuiBuilder == 1)
					return ProjectName + _T("_wxsmith.wxs") + _T(";") + GenerateHeader(file_index); // wxSmith file
				else if (GuiBuilder == 2)
					//return ProjectName + _T("_wxfb.fbp") + _T(";") + GenerateHeader(file_index); // wxFormBuilder file
					ShowInfo(ProjectName + _T("_wxfb.fbp") + _T(";") + GenerateHeader(file_index)); // This one is for testing
			}
		}
		else if (file_index == 5)
		{
			if (GuiBuilder == 2)
			{
				if (GuiAppType == 1)
					return ProjectName + _T("GUIFrame.h") + _T(";") + GenerateHeader(file_index);
				else if (GuiAppType == 0)
					return ProjectName + _T("GUIDialog.h") + _T(";") + GenerateHeader(file_index);
			}
		}
		else if (file_index == 6)
		{
			if (GuiBuilder == 2)
			{
				if (GuiAppType == 1)
					return ProjectName + _T("GUIFrame.cpp") + _T(";") + GenerateHeader(file_index);
				else if (GuiAppType == 0)
					return ProjectName + _T("GUIDialog.cpp") + _T(";") + GenerateHeader(file_index);
			}
		}
		else if (file_index == 7 && WantPCH) // This is to ensure that if WantPCH is true, then project file should be added
		{
			if (GuiBuilder == 1)
				return _T(""); // WIll be added later
			else if (GuiBuilder == 2)
			{
				if (GuiAppType == 0)
					return ProjectName + _T("GUIDialog.fbp") + _T(";") + GenerateHeader(file_index);
				else if (GuiAppType == 1)
					return ProjectName + _T("GUIFrame.fbp") + _T(";") + GenerateHeader(file_index);
			}
		}
	}
    return _T(""); // no more generated files
}

I'm also attaching the full source if you wish to test it. But please make a backup of old folder as this is not fully working yet.

There is another problem with the second method. Pre-processor definition to enable PCH support can't be customised. If I add the wxFB project file with/without parsing, it is going to break the PCH support.

Sorry mandrav, this one is a typo. It should be "There is another problem with the second method to parse wxFB project file. Pre-processor definition to enable PCH support can't be customised (as they are not available in Project file). If I add the wxFB project file with/without parsing, it is going to break the PCH support."

How come? Why can't you use WX_GCH instead of USE_PCH?

I'm afraid that may create problem when wxSmith support will be added. For all the three possible options (None, wxSmith and wxFormBuilder), the same Pre-processor definition would be helpful. Either we 3 settle for same Pre-processor flag or there should be options available to customise them.

[attachment deleted by admin]

[rjmyst3]

wxFB uses WX_GCH whereas the project will use USE_PCH.

 It would be pretty easy for wxFB to change to this:

Code

#if ( defined(WX_GCH) || defined(USE_PCH) )
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endif

That way existing projects setup with WX_GCH would not break, but it should also work the with Code::Blocks wizard.
Customization would be better, probably, but I'll need to talk to the other devs about adding a property.
Will that work for you?