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!
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.
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.
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.
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.
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:
mingw32-g++.exe -LE:\Libraries\wxMSW-2.8.0\lib\gcc_dll -o test.exe main.o app.o -lwxmsw28d_core -lwxbase28d -lwxmsw28d_adv
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.
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:CodeBut 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.mingw32-g++.exe -LE:\Libraries\wxMSW-2.8.0\lib\gcc_dll -o test.exe main.o app.o -lwxmsw28d_core -lwxbase28d -lwxmsw28d_adv
:: === 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 ===
winmm.lib, rpcrt4.lib, kernel32.lib, user32.lib, gdi32.lib, ole32.lib, oleaut32.lib, comctl32.lib, comdlg32.lib, uuid.lib, advapi32.lib, shell32.lib
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'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. :D
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.
$(OBJS)\minimal.exe: $(MINIMAL_OBJECTS) $(OBJS)\minimal_sample_rc.o
$(CXX) -o $@ $(MINIMAL_OBJECTS) $(LDFLAGS) $(__DEBUGINFO) $(__THREADSFLAG) -L$(LIBDIRNAME) -Wl,--subsystem,windows -mwindows $(__WXLIB_CORE_p) $(__WXLIB_BASE_p) $(__WXLIB_MONO_p) $(__LIB_TIFF_p) $(__LIB_JPEG_p) $(__LIB_PNG_p) -lwxzlib$(WXDEBUGFLAG) -lwxregex$(WXUNICODEFLAG)$(WXDEBUGFLAG) -lwxexpat$(WXDEBUGFLAG) $(EXTRALIBS_FOR_BASE) $(__UNICOWS_LIB_p) $(__GDIPLUS_LIB_p) -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32I'm not sure why the compilers work in such a way?? If anyone have any idea, please post.
Works like a charm, at least as far as I've tested it (using GCC). Any of the C::B devs feel like integrating it into the main project?
Works like a charm, at least as far as I've tested it (using GCC). Any of the C::B devs feel like integrating it into the main project?
We sure will, once a few people test it and report that it works fine :).
Great job Biplab :).
Well it looks great.
There is a problem that makes it so that it won't link right out of the box.
I chose everything default except I un-checked "Use wxWidgets dll".
It needs to set the Debug and Release targets policy to "Prepend target options to project options" See screen shot below.
PS. It works great when building against a dll version of wxWidgets.
well, I haven't looked at them. But I have one concern (will post another article about that somewhere next week), just make sure the header includes are ok, and just include what's needed.
For example the current simple wx project which is generated, it's header includes are not so nice.
DECLARE_EVENT_TABLE();DECLARE_EVENT_TABLE()Did you check with Static lib of wx?
Can you please post the problems you've faced?This is just a bit of the linking errors, but you get the idea.
Linking executable: bin\Release\cbWizTest2.exe
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_app.o):app.cpp:(.text+0x665): undefined reference to `InitCommonControls@0'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_app.o):app.cpp:(.text+0x680): undefined reference to `OleInitialize@4'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_app.o):app.cpp:(.text+0x8be): undefined reference to `OleUninitialize@0'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_statbr95.o):statbr95.cpp:(.text+0x16f): undefined reference to `CreateStatusWindowW@16'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_droptgt.o):droptgt.cpp:(.text+0x904): undefined reference to `CoLockObjectExternal@12'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_droptgt.o):droptgt.cpp:(.text+0x91c): undefined reference to `RegisterDragDrop@8'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_droptgt.o):droptgt.cpp:(.text+0x94e): undefined reference to `CoLockObjectExternal@12'
C:\devel\Libraries\wxWidgets2.8\lib\gcc_lib/libwxmsw28u.a(monolib_droptgt.o):droptgt.cpp:(.text+0x971): undefined reference to `RevokeDragDrop@4'Precompiling header: wx_pch.hwhen I have first compiled as a Debug target, then go and rebuild the Release target?
Compiling: main.cpp
cc1plus.exe: warning: wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
cc1plus.exe: warning: ./wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
Just a quick question for you, why do I get this message:QuotePrecompiling header: wx_pch.hwhen I have first compiled as a Debug target, then go and rebuild the Release target?
Compiling: main.cpp
cc1plus.exe: warning: wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
cc1plus.exe: warning: ./wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
Works great now. I have attached a screen shot of the settings that I used because I am not sure what you are exactly asking about when you said:QuoteDid you check with Static lib of wx?
Just a quick question for you, why do I get this message:QuotePrecompiling header: wx_pch.hwhen I have first compiled as a Debug target, then go and rebuild the Release target?
Compiling: main.cpp
cc1plus.exe: warning: wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
cc1plus.exe: warning: ./wx_pch.h.gch/Debug_wx_pch.h.gch: created using different flags
I get that message all the time.
Each time, I switch between debug and release, I have to do a Re-Build to rebuild the pre-compiled headers because the -g flag has been toggled.
I don't think it's a result of the new wizard.
It's really annoying.
Lately, I don't even bother creating a release target. I just turn off the -g flag and re-build. Seems just as convienent as dealing with the precompiled issue.
<Unit filename="wx_pch.h">
<Option compilerVar="CPP" />
<Option link="0" />
<Option weight="0" />
<Option target="Debug" />
<Option target="Release" />
</Unit>
...I prefer this method. It is simple, smart and makes it easy to use. Please keep it this way, or at least a setting.
Another problem with the sample code provided by the wizard is that it doesn't add wx_pch.h file to CPP files. Rather it is forcefully included. To me it should be included in the CPP file itself.
...Great I don't mind the warning I just wanted to make sure that I was still using pre-compiled headers in Release.
Pecan is right. It's not the fault of new wizard. Code::Blocks adds the file, required for pre-compilation, in target scope which is compiled, but not linked. As you can see that the file is added to Debug and Release target, it is compiled twice with different flags. See the following code.Code<Unit filename="wx_pch.h">
<Option compilerVar="CPP" />
<Option link="0" />
<Option weight="0" />
<Option target="Debug" />
<Option target="Release" />
</Unit>
Wish you all Happy New Year. :DHappy New year!
...I prefer this method. It is simple, smart and makes it easy to use. Please keep it this way, or at least a setting.
Another problem with the sample code provided by the wizard is that it doesn't add wx_pch.h file to CPP files. Rather it is forcefully included. To me it should be included in the CPP file itself.
...I prefer this method. It is simple, smart and makes it easy to use. Please keep it this way, or at least a setting.
Another problem with the sample code provided by the wizard is that it doesn't add wx_pch.h file to CPP files. Rather it is forcefully included. To me it should be included in the CPP file itself.
That all makes sense, I just don't want to loose the settings part for GCC and MSVC. If you need to add some lines to the code generated, no problem.
-H -H=<Bin_Dir>/<Target>/<Project_Name>.csm#include "wx/wxprec.h" or #include "wx_pch.h"
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__
/Yc"wx/wxprec.h"
/Fp"<Bin_Dir>\<Target>\<Project_Name>.pch"but pch can increase builds a lot also, it's interesting when using a library like wx with should remain rather static.
For example in CB sources , with the rate of current changes, a lot of the time the builds become longer because of pch.
I think the best thing is to have a correct project wizard without pch and then add the pch capabilities.
I have few queries.
- Does Code::Blocks support PCH for compilers other than GCC?
- How is the PCH handled internally by Code::Blocks?
This feature needs some planning in order to be generally available for all compilers that support PCHs.Quoted for truth. For instance, MSVC requires one to compile a PCH through a separate source file, and then specify that the header is a PCH in the command line for every file that needs to use it.
Great Biplab. When can I get my hands on the updated wizard code?
This feature needs some planning in order to be generally available for all compilers that support PCHs.
GCC seems to be worst among them. It needs the header and gch file to be in the same directory.
QuoteGCC seems to be worst among them. It needs the header and gch file to be in the same directory.
That is certainly not true. Why do you think there are the different PCH options in the project properties dialog? As long as the compiler can locate the .gch file before the .h one, it will use the PCH...
Any suggestions on what went wrong?As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).
Any suggestions on what went wrong?As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).
Any suggestions on what went wrong?As mandrav said, he "hard-coded" support for GCC precompiled headers. In effect, this means that any header that is marked to be compiled will follow whichever rule you choose in the Precompiled headers section of your project properties: generate the pch alongside the original header, in a subdirectory of the original header's directory, or in the object output directory (this last option introduces the "-I-" (I-split) switch, which can cause issues with other includes, particularly from external libraries).
And you can change this behaviour with your wizard by using the SetModeForPCH() function of cbProject...
As GCC uses the first GCH file found in file.h.gch folder, this problem arises.
QuoteAs GCC uses the first GCH file found in file.h.gch folder, this problem arises.
Another misconception here. GCC will use the gch that matches the running build. It just emits a warning for those gch that it ignores (you can avoid this warning by not defining the -Winvalid-pch option).
Just my personal thoughts on that (nice!!!) work:
- Wizard CPP files are modified to support PCH.
Just my personal thoughts on that (nice!!!) work:
- Wizard CPP files are modified to support PCH.
I wonder if it would make sense to separate the PCH feature into an own wizard. PCH isn't something possible for wx only (obviously). Do you think from your experience it would be possible to extract a "PCH enabling wizard" out of this one that can be applied to *any* project?
With regards, Morten.
I think wxUSE_UNICODE needs to be defined to a number
#define wxUSE_UNICODE 1
not just defined. That probably explains why BCC was upset.
I think wxUSE_UNICODE needs to be defined to a number
#define wxUSE_UNICODE 1
not just defined. That probably explains why BCC was upset.
For the other two compilers, GCC and MSVC, setting flag -DwxUSE_UNICODE or /DwxUSE_UNICODE does the job. With BCC I faced the problem. I changed it to -DwxUSE_UNICODE=1 but the problem remained. Then I've decided to change it to -DUNICODE and it worked.
Will look into it again. :)
Hi Everyone,
I write you here just to inform you about a little problem (I don't know if I can call it "bug", but I've been quite annoyed by that) in the wizard.
It seems that the generation of the linker libraries list produce a wrong ordered list (i.e. "libwxmsw28u_richtext.a" is putted after "libwxmsw28u_core.a", which gives rise to compilation's problems).
...and a big big sorry for my awful english language!
-------------- Build: Debug in vc8Test ---------------
Compiling: main.cpp
Compiling: app.cpp
main.cpp
app.cpp
c1xx : fatal error C1083: Cannot open compiler intermediate file: 'obj\Debug\vc8Test.pch': No such file or directory
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings
c1xx : fatal error C1083: Cannot open compiler intermediate file: 'obj\Debug\vc8Test.pch': No such file or directory
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings
Here are my problems with the wizard when compiling VC7.1 toolkit. I choose the monolithic Unicode library as the options.
- It is missing 'Rpcrt4.lib' from the library list.
- The run-time needs to be selected. For Debug it should be 'Mulit-threaded Debug Runtime Library' and for Release it should be 'Mulit-threaded Runtime Library'. This will also make it so that you manually don't need to add the msvcrt[d].lib in the vc8.0 setup.
- I had to add /NODEFAULTLIB:libcmtd.lib to the linker other options. (I think this might be fixed with building the libraries including the static runtime)
- I found out that I built the monolithic libraries without using the static run-time library which I will have to fix and repost wxPack. This will make the above work as expected. When using a static library there should be no reason to include a dll of the runtime. That defeats the purpose in my opinion.
More details to come after I fix the builds of the compiled wxWidgets.
#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
# pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")If you add wx_pch.h file in NOPCH mode, it has no effect on PCH generation. It includes wx/wxprec.h file only.That would be fine but you are not creating the wx_pch.h file at all. It is missing.
...Yes I am.
I'm assuming you are compiling an app with MSVC7.1 generated by new wizard.
Problem 1-3 will come as nothing has been added for MSVC 7.1 or 6. So you are getting those errors. I had deliberately skipped adding any compiler options to MSVC 7.1 (some are very similar to MSVC 8 ) as I couldn't test it.OK, well that explains why it doesn't work very well.
wx Dev team does not suggest us to use static library for MSVC in some cases. I'm quoting the following line from src/common/string.cpp file.I have done some reading and a bit of testing and have determined that the impact for most uses is minimal. In my opinion you should be able to use the statically linked library with no other files to distribute. (Yes I know the Windows is coming with them more and more) and if you would be willing to use the runtime dll you will be willing to use wxWidgets as a dll as well. So I think this is the best compromise between speed and extra files needed to distribute. :)Code#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
# pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")
This warning was one of the reason I took a longer route of embedding manifest file for MSVC 8 to exe file after the build is finished. And I think it would be better if you continue building wxPack with dynamic runtime lib. :D
If you add wx_pch.h file in NOPCH mode, it has no effect on PCH generation. It includes wx/wxprec.h file only.That would be fine but you are not creating the wx_pch.h file at all. It is missing.
wx Dev team does not suggest us to use static library for MSVC in some cases. I'm quoting the following line from src/common/string.cpp file.I have done some reading and a bit of testing and have determined that the impact for most uses is minimal. In my opinion you should be able to use the statically linked library with no other files to distribute. (Yes I know the Windows is coming with them more and more) and if you would be willing to use the runtime dll you will be willing to use wxWidgets as a dll as well. So I think this is the best compromise between speed and extra files needed to distribute. :)Code#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
# pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")
This warning was one of the reason I took a longer route of embedding manifest file for MSVC 8 to exe file after the build is finished. And I think it would be better if you continue building wxPack with dynamic runtime lib. :D
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
http://www.delta3d.org/article.php?story=20050721180227305&mod
http://root.cern.ch/root/Procedure/Procedure%20to%20install%20the%20free%20Microsoft%20Visual%20C.htmwxbase28d.lib(baselib_datetime.obj) : error LNK2001: unresolved external symbol _timezone
OLDNAMES.lib(timezone.obj) : error LNK2001: unresolved external symbol _timezone
OLDNAMES.lib(timezone.obj) : error LNK2001: unresolved external symbol __timezone
One Request to wx Gurus. If anyone has info regarding correct wx lib order and how to find them out (from .lib files, if possible) please post it here. I've found the build order from wx dlls using Dependency Walker. But I would like to know how you devs solve the problem. :DI simply used the order provided by the wx samples.
Just wanted to say thanks for the wizard. I used Rev3 to start my new Project with wxWidgets 2.6.3 and I was able to make 2 different targets for MinGW (this target is used to be sure that my code is GCC friendly, for Linux use) and for VC++ (used to compile faster and produce more compact exe in Windows).
Everything was compiled using static libraries, monolithic for MinGW and modular for VC++. Went well for dll use also.
Thanks a lot as I had really no idea on how to begin with wxWidgets !!
Despite the release of 6 revisions, I've received very few feedbacks. Thus I've decided to add a Poll in this thread. Please rate it if you have tested it. That would help us improving it further. Thanks in advance for your time. :)Hi Biplab,
Hi Biplab,
you are doing a realy great job here :D
I'm using your Wizard a lot.
I would add an option to customize wx's lib filenames and paths since mine (compiled using msys) are different to the default ones. So I have to accept the error message, change the library names and modify the directories. This can make starting with wx very hard for beginners.I have never used MSYS and wxWidgets together. So I've to figure out this one. But can you give me an idea about any advantage of using MSYS in windows? I compile wx with GCC without using MSYS.
Being able to choose between different presets or even better, the wizard could try to autodetect the available configuration.Using presets is a Good Idea. But the sheer amount of combination can be confusing. Autodetection of config is difficult, but can be implemented somehow.
Being able to choose from different application types e.g.:Can be done. But honestly I need to know how to instruct wizard to copy the required set of files. :)
- a completely empty project (so the wizard would just set up the project options)
- an empty project with just a wxApp derived class
- app with wxDialog
- app with wxFrame
customize window:May not be possible. To do this with C::B, wizard has to set few additional preprocessor directives which would make your project clumsy.
- title
- menu
- toolbar
- statusbar
- style
(optionally) add a default icon (cb-icon? :)), so user will just have to edit this icon. I remember all those apps out there, coming with the default blue Microsoft MFC-icon (sometimes even "professional" software) :lol:Icons will work in Windows, but not in Linux. So they are excluded to avoid clashes in Linux.
being able to customize the name of the created classes and filenames!!Not possible at the moment.
I have never used MSYS and wxWidgets together. So I've to figure out this one. But can you give me an idea about any advantage of using MSYS in windows? I compile wx with GCC without using MSYS.You don't have to setup any paths :D. Seriously, as people have the choice, they will always decide differently.
Using presets is a Good Idea. But the sheer amount of combination can be confusing. Auto detection of config is difficult, but can be implemented somehow.Maybe add some presets like (wxPack, mingw32-make, msys). Auto detection will require some work.
Can be done. But honestly I need to know how to instruct wizard to copy the required set of files. :)After a quick look on your script, I think GetFilesDir() returns the directories containing the files.
May not be possible. To do this with C::B, wizard has to set few additional preprocessor directives which would make your project clumsy.Solving this with preprocessor directives surely is the wrong way. What we would need is the possibility of modifying the generated sourcefiles. Creating a temp directory, copying the files there, modifying them, let codeblocks copy them to the project dir and deleting the temp dir would be a alternative, but implementing this cross-platform is very hard.
Icons will work in Windows, but not in Linux. So they are excluded to avoid clashes in Linux.Then make it a Windows feature only. I think there are enough win developers out there that the "wow, that was easy" effect would be pay off :D
Would be possible with the callback function (see above).being able to customize the name of the created classes and filenames!!Not possible at the moment.
I didn't know that the wizards are scripted. Squirrel? Never heard of it :shock:
I just had a quick look, but I think you are right, the possibilities currently are very limited :?
You don't have to setup any paths :D. Seriously, as people have the choice, they will always decide differently.I understand your point. But to support MSYS, the code overhead will be high. I've noticed that the naming convention of resulting wx libraries and directories are different from what is being used for other compilers in Windows or when you are using makefile to compile wx libs using GCC. Another point to remember that the automatic path setup depends upon a shell script which is not independent to execute.
Maybe add some presets like (wxPack, mingw32-make, msys). Auto detection will require some work.wxPack comes with a lot of combinations. Which one should be made the Default One? IMHO, Putting 4 Checkboxes (Debug/Release; Static/Dynamic; ANSI/Unicode; Multi-lib/Monolithic) will be helpful to users rather than putting 16 options in a combo.
After a quick look on your script, I think GetFilesDir() returns the directories containing the files.Thanks for pointing this. I'll play with it. :)
So you would have to add a directory for every possibility. I hate redundant data :?
Solving this with preprocessor directives surely is the wrong way. What we would need is the possibility of modifying the generated sourcefiles. Creating a temp directory, copying the files there, modifying them, let codeblocks copy them to the project dir and deleting the temp dir would be a alternative, but implementing this cross-platform is very hard.I think you should put a feature request, expressing your idea on how to do that. C::B devs will surely listen to you.
The easiest and cleanest way would be codeblocks providing something like a callback function with the source filename and content as parameter allowing the wizard developers to modify them with string manipulation.
Then make it a Windows feature only. I think there are enough win developers out there that the "wow, that was easy" effect would be pay off :DI've added it in my to-do list. Will try to come up with it. :)
Until now you didn't even know that wizards are script-driven and now you already think they 're too limited.Well, sorry, you misunderstood me.
Let me tell you something: you don't even know what a script is capable of.Are you sure? Just wonder how good you have to know me...
And until you do, please refrain from criticizing other people's work.As I said, my intention wasn't to criticize anything (especially not cb).
I love it when someone who has no clue on how something works, has already an opinion on it...I love it when people blame each other to have no clue, especially if they know each others as good as we.
@Biplab
What about this:
First, let the user decide what method of wx-building he used (wxpack, mingw32-make, msys).
On the next panel, put the 4 checkboxes you said and maybe add something like "auto detect" which tries do find the right configuration available. Since if you know the path to the libs and the "build method", finding out the configuration shouldn't be too hard (trial and error).
Let me tell you something: you don't even know what a script is capable of.Are you sure? Just wonder how good you have to know me...I love it when someone who has no clue on how something works, has already an opinion on it...I love it when people blame each other to have no clue, especially if they know each others as good as we.
I didn't know that the wizards are scripted. Squirrel? Never heard of it :shock:
I just had a quick look, but I think you are right, the possibilities currently are very limited :?
...
I haven't ever looked at cb's source, but I think
...
One news, I've modified the wizard now to include Resource files and Icons in Windows. I've used standard wxWidgets Icon. Will post it after testing in Linux.Good news 8)
And just for the record, all things that you have entioned as "wizards' limitations", are possible for quite some time now.So what do you suggest?
And just for the record, all things that you have entioned as "wizards' limitations", are possible for quite some time now.So what do you suggest?
What do you think about an panel to let the user modify the names of the libs manually, after the "configuration could not be found" message occurred?Take this one. For an advanced user, if he gets the warning message saying that the configuration is not found he'll either use appropriate configuration or add the required libs in the project manually.
Ahh! Creating an empty file gives me all kinds of ugly linking errors!
I don't know why, but it works now :? I think I may have found a bug with at least empty project, if not all projects: if you select created precompiled header, it is never created and thus at build time you get an error that it does not exist. Fixes?
I downloaded CB revision 3558, and installed it in a new directory, with the two extra dlls.
I downloaded wxWidgets version 2.8.0 then 2.6.3
I used the wizard to create lots of different non-empty projects. For each one, I compiled the project immediately, with the standard compiler, without modifying anything. I created some of them with 2.8.0, others with 2.6.3.
Some projects with or without unicode, with or without debug, or with release, ... I tried lot of the options available.
All projects generated more than 50 errors.
Most of them are in chkconf.h.
The first is usually "wxUSE_EXCEPTIONS must be defined."
then lots of wxUSE_ constants seem not defined.
If I'm correct the wizard currently will use the same library type (either Shared or Static) for both the Release Build and the Debug build.
My question is the following:
Would it be possible to extend the wizard such that the user can select different project options (Use wxWidgets DLL, wxWidgets is built as a monolithic library and Enable unicode) for Release Builds and for Debug Builds?
I downloaded CB revision 3558, and installed it in a new directory, with the two extra dlls.
I downloaded wxWidgets version 2.8.0 then 2.6.3
I used the wizard to create lots of different non-empty projects. For each one, I compiled the project immediately, with the standard compiler, without modifying anything. I created some of them with 2.8.0, others with 2.6.3.
Some projects with or without unicode, with or without debug, or with release, ... I tried lot of the options available.
All projects generated more than 50 errors.
Most of them are in chkconf.h.
The first is usually "wxUSE_EXCEPTIONS must be defined."
then lots of wxUSE_ constants seem not defined.
Did you compile wxWidgets?? You have downloaded the source of wxWidgets which needs to be compiled. It seems that compiler can't find setup.h.
Isn't CB able to compile a program AND its librairies?Technically speaking, C::B isn't able to compile anything. (GCC, or whatever other compiler you choose, does the footwork.) That said, large libraries generally come with their own specific method of compilation, and wxWidgets is no exception to this rule. The C::B wiki contains straightforward instructions on how to compile wxWidgets.
Forgot to mention that I did manage to set up a project where Release Target and Build Target use different library types.
The project uses a shared library for the Debug Target and a static library for the Release Target.
The project was created the wxWidgets wizard with the "Use wxWidgets DLL" check box checked.
I changed the following "Project build options" manually:
a) In the Compiler tab moved #define WXUSINGDLL from "Project" (settings used for both Debug and Release Target) to "Debug"
b) Release Target - Linker tab
added Link libraries: libwxmsw28u.a, comctl32, gdi32, ole32, oleaut32 and uuid
c) Release Target - Directories tab
Compiler tab: change <path>\wxWidgets-2.8.0\lib\gcc_dll\mswud to
<path>\wxWidgets-2.8.0\lib\gcc_lib\mswu
Linker tab: change <path>\wxWidgets-2.8.0\lib\gcc_dll to
<path>\wxWidgets-2.8.0\lib\gcc_lib
Resource compiler tab: change <path>\wxWidgets-2.8.0\lib\gcc_dll\mswud to
<path>\wxWidgets-2.8.0\lib\gcc_lib\mswu
With these changes the Debug Target and the Release Target build succesfully.
I'll also check your suggestion to see which "trick" is easiest to use.
A short remark for other newbies who might think "why would you like different library types in the first place?"
For Release Targets I prefer to have an executable that doesn't depend on DLL files, hence the static library.
For the Debug Target I could use a static wxWidgets debug library. But the static wxWidgets library has a big disadvantage (when compiled with MinGW GCC) if you are short on HDD space: it is huge, about 360 MByte. The shared wxWidgets library "only consumes" about 75 MByte.
Isn't CB able to compile a program AND its librairies?
If you don't want to compile wxWidgets on your own, then download wxPack.
I downloaded CB revision 3558, and installed it in a new directory, with the two extra dlls.
I downloaded wxWidgets version 2.8.0 then 2.6.3
I used the wizard to create lots of different non-empty projects. For each one, I compiled the project immediately, with the standard compiler, without modifying anything. I created some of them with 2.8.0, others with 2.6.3.
Some projects with or without unicode, with or without debug, or with release, ... I tried lot of the options available.
All projects generated more than 50 errors.
Most of them are in chkconf.h.
The first is usually "wxUSE_EXCEPTIONS must be defined."
then lots of wxUSE_ constants seem not defined.
Did you compile wxWidgets?? You have downloaded the source of wxWidgets which needs to be compiled. It seems that compiler can't find setup.h.
Also post more details.
OK, thanks, it worked.
You should group these 4 major parameters in the same panel, and make this obvious. For example, gray the options that do not correspond to the compiled wxWidgets, if not too complex to do.
One more question: after compilation & execution OK, i tried to add one character in the title of the window, an acute letter. I got the message "Illegal byte sequence".
One more question: after compilation & execution OK, i tried to add one character in the title of the window, an acute letter. I got the message "Illegal byte sequence".
One more question: after compilation & execution OK, i tried to add one character in the title of the window, an acute letter. I got the message "Illegal byte sequence".
GCC needs to be told the character set used in your code. The compiler option is named "-finput-charset" and takes the encoding as argument. The default value is "-finput-charset=utf-8" (if I 'm not mistaken).
wx lib configurations are conveniently grouped now. See the following screenshot for more details. The changes are Windows specific.
Committed in Revision 3570.
Thanks ascx.....
For the time being you can use alternate method. Use workspace.
- First create one wx project with one lib config, le's say static-unicode-non-monolithic. Keep this project open.
- Create second wx project with another lib config, let's say dll-unicode-monolithic. You've to create it in a different folder.
- Now remove generated source (if you've ur own source) and add same source to both the projects.
- Now save the workspace from File > Save workspace menu. From next time onwards, open the workspace and code::blocks will load both the projects.
You can uncheck the appropriate target for appropriate projects. E.g., if you wish that the first project will be built in debug mode then uncheck release target during project creation.
I agree that my suggestion may not be the best one, but it should work. :D
Regards,
Biplab
One more question: after compilation & execution OK, i tried to add one character in the title of the window, an acute letter. I got the message "Illegal byte sequence".
GCC needs to be told the character set used in your code. The compiler option is named "-finput-charset" and takes the encoding as argument. The default value is "-finput-charset=utf-8" (if I 'm not mistaken).
With this option, must i compile wxWidgets, just my application, or both?
Is this option available in CB, like Settings|compiler? i didn't find it.
GCC uses UTF-8 unless told otherwise...
GCC uses UTF-8 unless told otherwise...
with the last nightly build on XP
1) With the wizard i created a project. The automatically generated files appears in the "Management" CB windows.
2) i re-run the wizard to re-create the project with the same parameters. It ask if i want to overwrite => Yes
3) then a dialogbox says that one file has been changed outside the IDE. "Do you want to reload it" => Yes for each
4) Result: in the "Management" windows, the files *.h and *.cpp appear two times each, even if they can only be opened once each.
5) I re-run a third time the wizard with same parameters: the files appear 3 times each, and so on.
The Bug has been fixed. Patch submitted. Will be updated soon. :)Thank you :D
* Use a different project name. ;)
Another point, which is not really a bug, just not logical:
After choosing the version of wxWidgets you want/have, you choose the directory only 3 panels afterwards :shock: As the version and the directory of wxWidgets are closely-related informations, they should be chosen either in the same panel, or in two consecutive panels.
is it possible for 2 consecutive pages?
What I propose is to add one more option (One checkbox) saying Use Debugging wx Libraries for Both Targets in this page for Advanced Users. If you check it, it'll add debug wx libs to both targets.
IMHO, putting these advanced options in a separate page would be less confusing for newbies. :)
Is it OK?
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.
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.
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? :)
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).
In my valuable opinion ( 8) ) 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,
If I were to supply you with a patch that added a "Use wxFormBuilder (http://www.wxformbuilder.org) for GUI Design" checkbox to the wizard and generated the necessary files, what are the chances that you would accept it?
@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 ;) )
...
@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. :)
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 ;) )
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. :)
wxFormBuilder does support event handlers now as well as having a wizard to generate your inherited class. These are in in wxFormBuilder v3.0+
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.
This should work.
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.
#include "TestApp.h"
class TestFrame: public wxFrame#include "TestApp.h"
#include "TestFrameGUI.h"
class TestFrame: public TestFrameGUI1. 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.
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.Codewhere TestFrameGUI class will be generated by wxFB.#include "TestApp.h"
#include "TestFrameGUI.h"
class TestFrame: public TestFrameGUI
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.
- 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.
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.
(http://img258.imageshack.us/img258/7646/wxguiselectalpha1uj3.th.png) (http://img258.imageshack.us/my.php?image=wxguiselectalpha1uj3.png)
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
#ifdef WX_GCH
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endifProblem 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. 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.
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.
[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
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
}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?
wxFB uses WX_GCH whereas the project will use USE_PCH.
#if ( defined(WX_GCH) || defined(USE_PCH) )
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endif
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.This would be a nice addition. :)
@byo
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. :)
Yes! This will work. But I'll request you to NOT to add this immediately. Because I'm not sure about wxSmith. These three options need a common Pre-processor define to avoid this problem. :D
Project file for wxDialog-based app is in attachment :) I've added some content into dialog since wxDialog can not have menus nor toolbars
wxSmith uses the same scheme as in current wizard, this can be changed without any harm to wxSmith's behaviour. Maybe current content of files could be tweaked a little bit because wxSmith always generates list of includes in source/header files - these could be disabled when using PCH by putting inside #if block. wxSmith should easily handle this :)
#ifdef WX_GCH
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endifIMHO, the following code is bit redundant.Code#ifdef WX_GCH
#include <wx_pch.h>
#else
#include <wx/wx.h>
#endif
During compilation of cpp file, this code may not play a big role.
local ProjectName = Wizard.GetProjectName();
WxsAddWxExtensions(project,ProjectName+_T("App.cpp"),ProjectName+_T("Main.cpp"),ProjectName+_T("Main.h"),_T("wxsmith/")+ProjectName+_T("dialog.wxs"));
The only thing I haven't found out yet is how to check if WxsAddWxExtensions function is defined using script's code - if it's not, wxSmith RAD should be disabled (or it should show some message).
if ("WxsAddWxExtensions" in getroottable())
{
...
}
Codeif ("WxsAddWxExtensions" in getroottable())
{
...
}
@byo: it's great that you added the first wxSmith script binding :). But make sure to de-register it when the plugin is unloaded (at least if the app is not shutting down). If you don't know how to do it, check compilergcc.cpp: it does this for a script function named "BuildLog" iirc.
EDIT:It is as simple as that:
I guess that mentioned function is not unregistered in compilergcc.cpp coz I couldn't find it :(
// disable script functions
ScriptBindings::gBuildLogId = -1;
EDIT:It is as simple as that:
I guess that mentioned function is not unregistered in compilergcc.cpp coz I couldn't find it :(Code(in void CompilerGCC::OnRelease(bool appShutDown))... If I get Yiannis correctly.// disable script functions
ScriptBindings::gBuildLogId = -1;
With regards, Morten.
Manager::Get()->GetScriptingManager();
HSQUIRRELVM v = SquirrelVM::GetVMPtr();
if ( v )
{
sq_pushroottable(v);
sq_pushstring(v,"WxsAddWxExtensions",-1);
sq_deleteslot(v,-2,false);
sq_poptop(v);
}@byoNo problem, there's no rush. I hope to have it in 1.0 final, and it rather won't be released in a week ;)
wxSmith support will be added after I finish this one. :)
Supports Only wxFormBuilder+wxFrame based app.
@rjmyst3
Please test it once and give your feedback. :)
I tested wxFB + wxFrame on Windows XP, and it worked flawlessly. Very Nice! :D
I only have one suggestion:
The title for the frame ("wxWidgets Application Template") should be set in wxFB. Otherwise the user will not be able to easily change it in wxFB later.
#include "wx_pch.h"#ifdef WX_PRECOMP
#include "wx_pch.h"
#endifI think wrapping the include with appropriate Pre-Processor definition will be the best solution of this problem. Presently wxFB generated files include <wx/wxprec.h> by default which is always available and thus this issue have not come up earlier. Though this works, IMHO, creating custom PCH file will be beneficial for large projects. Smile
BEGIN_EVENT_TABLE(<generated Frame Name>, wxFrame)BEGIN_EVENT_TABLE(<generated Frame Name>, GUIFrame)@rjmyst3
Please check the new release once (in Windows and Linux) and provide your feedback and suggestions. :D
Dialog* dlg = new Dialog(0L, _("wxWidgets Application Template"));
Dialog( wxDialog *dlg );
Dialog::Dialog(wxDialog *dlg)
: GUIDialog(dlg)
{
}
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? :)
I saw that you updated the title in wxFB, however, App.cpp sets it again in this line:CodeThis code will always override what wxFB generates, so the user still cannot change the title in wxFB.Dialog* dlg = new Dialog(0L, _("wxWidgets Application Template"));
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. :D
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 ;)
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.
#include "wx_pch.h"
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__
#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__
#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMP
http://forums.codeblocks.org/index.php?topic=4768.msg40734#msg40734
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__
#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif //WX_PRECOMPFollowing 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
#ifdef WX_PRECOMP
#include <pch header file>
#ifdef __BORLANDC__
#pragma hdrstop
#endif //__BORLANDC__
#else
#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?
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? :)
wxFB will convert them.
You can expect a new build today - hopefully within the hour. 8)
1) I installed CB version 3565 on XP
2) I installed wxWidgets 2.8.0 and compiled it with gcc with unicode => OK
3) use of the wizard to generate a basic application with unicode => compile and execute OK with gcc
4) Then without modifying any CB option anywhere, i just add the special letter é to the title of the windows:
original line, generated by the wizard
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Template"));
modified line, for beginning to test the unicode support
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Templateé"));
no other modification except this character => i got the compile message "Illegal byte sequence".
5) If i suppress this character => compile OK
6) I've now tried several times with last build 3577 => same problem, but the error message is now
"converting to execution character set: Invalid argument"
1) I installed CB version 3565 on XP
2) I installed wxWidgets 2.8.0 and compiled it with gcc with unicode => OK
3) use of the wizard to generate a basic application with unicode => compile and execute OK with gcc
4) Then without modifying any CB option anywhere, i just add the special letter é to the title of the windows:
original line, generated by the wizard
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Template"));
modified line, for beginning to test the unicode support
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Templateé"));
no other modification except this character => i got the compile message "Illegal byte sequence".
5) If i suppress this character => compile OK
6) I've now tried several times with last build 3577 => same problem, but the error message is now
"converting to execution character set: Invalid argument"
I was having the same problem,
First goto the menu "Project->Build Options" then click your project name. Inside of your global project settings select "Compiler Settings" then click "Other Options" tab, now in that multiline text control write this:
-finput-charset=iso-8859-1
That will fix the problem compiling the standard Latin characters available in the ascci table: á é í ó ú ñ Ñ É and others I does not remember. :)
-finput-charset=iso-8859-1
(...)
I wonder, why such an important option have to be put manually in the "other options" tab? If you use Unicode, this option is mandatory!
1) I installed CB version 3565 on XP
2) I installed wxWidgets 2.8.0 and compiled it with gcc with unicode => OK
3) use of the wizard to generate a basic application with unicode => compile and execute OK with gcc
4) Then without modifying any CB option anywhere, i just add the special letter é to the title of the windows:
original line, generated by the wizard
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Template"));
modified line, for beginning to test the unicode support
azeFrame* frame = new azeFrame(0L, _("wxWidgets Application Templateé"));
no other modification except this character => i got the compile message "Illegal byte sequence".
5) If i suppress this character => compile OK
6) I've now tried several times with last build 3577 => same problem, but the error message is now
"converting to execution character set: Invalid argument"
I was having the same problem,
First goto the menu "Project->Build Options" then click your project name. Inside of your global project settings select "Compiler Settings" then click "Other Options" tab, now in that multiline text control write this:
-finput-charset=iso-8859-1
That will fix the problem compiling the standard Latin characters available in the ascci table: á é í ó ú ñ Ñ É and others I does not remember. :)