Author Topic: Modified & Improved wxWidgets Project Wizard  (Read 242913 times)

Offline RJP Computing

  • Almost regular
  • **
  • Posts: 135
    • RJP Computing
Re: Modified & Improved wxWidgets Project Wizard
« Reply #150 on: February 16, 2007, 09:19:09 pm »
@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+
« Last Edit: February 16, 2007, 09:30:24 pm by RJP Computing »
- Ryan

Ubuntu/WinXP, AMD Athlon 64 3000+, 1000MB RAM, AC 97 Audio, ATI Radeon 9600XT 256MB

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 836
Re: Modified & Improved wxWidgets Project Wizard
« Reply #151 on: February 16, 2007, 09:53:03 pm »
@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

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: Modified & Improved wxWidgets Project Wizard
« Reply #152 on: February 16, 2007, 10:11:18 pm »
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.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: Modified & Improved wxWidgets Project Wizard
« Reply #153 on: February 17, 2007, 02:22:51 am »
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!
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Modified & Improved wxWidgets Project Wizard
« Reply #154 on: February 17, 2007, 07:48:35 am »
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
« Last Edit: February 17, 2007, 10:25:19 am by Biplab »
Be a part of the solution, not a part of the problem.

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: Modified & Improved wxWidgets Project Wizard
« Reply #155 on: February 17, 2007, 02:22:25 pm »
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!  :D

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: Modified & Improved wxWidgets Project Wizard
« Reply #156 on: February 17, 2007, 06:49:04 pm »
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.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Modified & Improved wxWidgets Project Wizard
« Reply #157 on: February 17, 2007, 07:17:37 pm »
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.
Be a part of the solution, not a part of the problem.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 836
Re: Modified & Improved wxWidgets Project Wizard
« Reply #158 on: February 17, 2007, 08:05:33 pm »
  • 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]

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Modified & Improved wxWidgets Project Wizard
« Reply #159 on: February 17, 2007, 08:26:36 pm »
Thanks Byo for the code. I'll go through it. :D

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
Be a part of the solution, not a part of the problem.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 836
Re: Modified & Improved wxWidgets Project Wizard
« Reply #160 on: February 17, 2007, 08:55:21 pm »
Thanks Byo for the code. I'll go through it. :D

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

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Modified & Improved wxWidgets Project Wizard
« Reply #161 on: February 19, 2007, 08:06:50 am »
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.
« Last Edit: February 19, 2007, 10:51:56 am by Biplab »
Be a part of the solution, not a part of the problem.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Modified & Improved wxWidgets Project Wizard
« Reply #162 on: February 19, 2007, 10:21:13 am »
Quote
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.

Quote
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?

Be patient!
This bug will be fixed soon...

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Modified & Improved wxWidgets Project Wizard
« Reply #163 on: February 19, 2007, 10:47:08 am »
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.

Quote
[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. :)

Quote
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]
« Last Edit: February 19, 2007, 11:02:56 am by Biplab »
Be a part of the solution, not a part of the problem.

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: Modified & Improved wxWidgets Project Wizard
« Reply #164 on: February 19, 2007, 03:11:50 pm »
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?