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

Biplab · « **Reply #180 on:** February 23, 2007, 03:54:09 pm »

Thanks for the feedback.

I'll update it and post it.

Biplab · « **Reply #181 on:** February 23, 2007, 07:03:37 pm »

Here is another update.

Features:

Now it's possible to select wxFrame/wxDialog based without using GUI builder.
wxFB will now handle Event handling of generated projects by default.
Now wxDialog based apps have cute wxWidgets icon in the main dialog.
Bugfix: Incomplete code generation when no GUI builder is selected.

Known Issues:

Compilation will fail in Non-PCH+wxFB Mode. Please see the thread (http://forums.codeblocks.org/index.php?topic=4768.msg40916#msg40916) for solution.

@rjmyst3
Please check the new release once (in Windows and Linux) and provide your feedback and suggestions.

I'm proposing one solution for this annoying known bug. I'll revert the PCH header include of wxFB generated files to <wx/wxprec.h> untill you wrap it. For the remaining files this will not be used. Once you fix this issue, please inform me and I'll update the wizard. What's ur opinion?

Regards,

Biplab

[attachment deleted by admin]

rjmyst3 · « **Reply #182 on:** February 23, 2007, 07:51:19 pm »

Quote from: Biplab on February 23, 2007, 07:03:37 pm

@rjmyst3
Please check the new release once (in Windows and Linux) and provide your feedback and suggestions.

Works great in Windows, I'll test in Linux tonight.
Good work on the event handling, that is much better.
I saw that you updated the title in wxFB, however, App.cpp sets it again in this line:

Code

Dialog* dlg = new Dialog(0L, _("wxWidgets Application Template"));

This code will always override what wxFB generates, so the user still cannot change the title in wxFB.

The constructor for the class should probably just take a parent parameter, like this:
Main.h

Code

Dialog( wxDialog *dlg );

Main.cpp

Code

Dialog::Dialog(wxDialog *dlg)
    : GUIDialog(dlg)
{
}

It is the same for Frame.

Quote from: Biplab on February 23, 2007, 07:03:37 pm

I'm proposing one solution for this annoying known bug. I'll revert the PCH header include of wxFB generated files to <wx/wxprec.h> untill you wrap it. For the remaining files this will not be used. Once you fix this issue, please inform me and I'll update the wizard. What's ur opinion?

That should work. I have approval from one of the devs to wrap it, I'm still waiting for the other's opinion. I hope to have it resolved this weekend.

Overall, excellent work. This is very exciting for me!

Biplab · « **Reply #183 on:** February 23, 2007, 08:54:26 pm »

Thanks for the quick feedback.

Quote from: rjmyst3 on February 23, 2007, 07:51:19 pm

I saw that you updated the title in wxFB, however, App.cpp sets it again in this line:
Code
Dialog* dlg = new Dialog(0L, _("wxWidgets Application Template"));
This code will always override what wxFB generates, so the user still cannot change the title in wxFB.

I forgot that somehow. This issue has been resolved. Latest revision is attached.

Quote from: rjmyst3 on February 23, 2007, 07:51:19 pm

That should work. I have approval from one of the devs to wrap it, I'm still waiting for the other's opinion. I hope to have it resolved this weekend.

If that change breaks other or deviates from the development plan that wxFB team have adopted, then you may wish to provide it as an add-on. Means, by default wxFB will remain same but if user wishes then wxFB will wrap it. I don't want to be too demanding.

If everything is ok, then I'm planning to put it in main repository this weekend.

Regards,

Biplab

[attachment deleted by admin]

rjmyst3 · « **Reply #184 on:** February 24, 2007, 02:00:58 am »

I tested the wxFB portion of the wizard on Linux - it works perfectly, minus pch support of course. I confirm that the title bug is fixed.
I'm very happy with it.

Two thumbs up

Quote from: Biplab on February 23, 2007, 08:54:26 pm

If that change breaks other or deviates from the development plan that wxFB team have adopted, then you may wish to provide it as an add-on. Means, by default wxFB will remain same but if user wishes then wxFB will wrap it. I don't want to be too demanding.

This issue will be resolved in some way this weekend.

Biplab · « **Reply #185 on:** February 24, 2007, 08:16:22 pm »

Thanks a lot.

I'll try to commit it tomorrow (I need to clean the code

).

Biplab · « **Reply #186 on:** February 25, 2007, 07:37:11 pm »

A Big update has been applied today.

Newer Features:

Wizard now Wizard now supports creation of wxDialog / wxFrame based app.
Wizard now supports wxFormBuilder to be selected as 3rd-Party GUI Builder alongwith wxDialog / wxFrame option.

Modifications:

PCH include header has been reverted to wx_pch.h
PCH Pre-Processor definition has been changed to WX_PRECOMP

Many Thanks To:

rjmyst3 and byo for raising the feature request.
byo for supplying the wxDialog template.
rjmyst3 for testing the development versions and providing valuable feedback for tighter integration with wxFormBuilder.

Known Issues:

There is one issue with PCH support. Presently all the apps generated will compile successfully. But there will be an additional amount of Pre-Compiled Header generated in some cases.

wxSmith support will be added soon.

Committed in revision 3543 and 3544.

Regards,

Biplab

byo · « **Reply #187 on:** February 26, 2007, 01:01:07 am »

Quote from: Biplab on February 25, 2007, 07:37:11 pm

wxSmith support will be added soon.

Should I start working on the "special function" added to squirrel? IT should be done in one day, but probably current Message-Box implementation would be better for testing purposes

BYO

Biplab · « **Reply #188 on:** February 26, 2007, 06:05:36 am »

Quote from: byo on February 26, 2007, 01:01:07 am

Should I start working on the "special function" added to squirrel? IT should be done in one day, but probably current Message-Box implementation would be better for testing purposes

Please add it. As the first part is over, adding wxSmith support should not take much time.

Biplab

rjmyst3 · « **Reply #189 on:** February 26, 2007, 03:45:54 pm »

Quote from: Biplab on February 25, 2007, 07:37:11 pm

Known Issues:
There is one issue with PCH support. Presently all the apps generated will compile successfully. But there will be an additional amount of Pre-Compiled Header generated in some cases.

I did some more looking into this. The way wxFB works right now is, if the "precompiled_header" property has content, the #include statement will be generated, but if left empty, wxFB does not generate anything.

So I suggest:
If the user wants pch support, set wxFB's "precompiled_header" property to "wx_pch.h", and wxFB will generate this:

Code

#include "wx_pch.h"

#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP

If the user does not want pch support, set the property to nothing (an empty string) and wxFB with generate this:

Code

#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP

The wizard should be able to modify the contents of wxFB's .fbp file to change the property, just as it would any other source file. It is just xml.

Will this solve the pch problem?

Biplab · « **Reply #190 on:** February 26, 2007, 04:14:41 pm »

Thanks for the suggestion.

Initially I started with parsing and generating custom wxFB project files. But C::B was refusing to add it. Thus I dropped the idea. See more details on the following thread.

Quote

http://forums.codeblocks.org/index.php?topic=4768.msg40734#msg40734

I've not looked into the issue yet. Once we figure this out, I'll make necessary changes.

Currently, few more MB of pch file will be generated with BCC and VC.

But I'm not quite sure whether that will solve the problem or not.

AFAIK, compiler will expect similar headers across all the cpp files to create the pch file. Once you issue the following command, BCC will be in trouble. Following code will tell BCC to create a PCH file without any header includes which may create utter confusion for the compiler and most probably will fail to compile.

Code

#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP

The best solution is to use, <wx/wxprec.h> across all the files but this will limit fine tuning if necessary. There will be another problem with GCC in this case. GCC requires <wx/wxprec.h> and <wx/wxprec.h.gch> to be at the same folder or the folder name containing *.gch file to be matching to compile.

This could create problems with C::B. C::B would then require this file to be added as a part of the project.

So you can see I'm also confused.

rjmyst3 · « **Reply #191 on:** February 26, 2007, 04:39:41 pm »

Quote from: Biplab on February 26, 2007, 04:14:41 pm

Following code will tell BCC to create a PCH file without any header includes which may create utter confusion for the compiler and most probably will fail to compile.

Code
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP

It seems as that is a bad idea then. So the #pragma hdrstop for borland is only necessary when using a pch?

Should the pch block look more like this?

Code

#ifdef WX_PRECOMP

#include <pch header file>

#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__

#else

#include <wx/wx.h>

#endif //WX_PRECOMP

Biplab · « **Reply #192 on:** February 26, 2007, 04:49:30 pm »

Quote from: rjmyst3 on February 26, 2007, 04:39:41 pm

It seems as that is a bad idea then. So the #pragma hdrstop for borland is only necessary when using a pch?

You are correct. That is necessary to tell BCC to stop at that point. Unless BCC gets that pragma, it will include all header file in that cpp file to generate compiled pch file.

IMHO, your solution should work. I'll try and update you more details whether this works or not.

rjmyst3 · « **Reply #193 on:** February 26, 2007, 05:35:01 pm »

wxFB now generates that code, as of svn revision 899.

Also, we recently had to uprev our project file for an unrelated change, so if the wizard were to generate .fbp files of version 1.6, then older versions of wxFB would refuse to open them, thus ensuring that users have a recent enough version. This could be helpful for non-pch mode, at least.

Biplab · « **Reply #194 on:** February 26, 2007, 05:40:26 pm »

I'm using Feb 17, 2007 build (3.0.20 beta 3) which produces v1.5 project files. So do I need to update the project files or wxFB will convert it once opened?

Code::Blocks Forums

News: