wxWidgets even worth it?

[algumacoisaqq]

Well, several times I have tried to use wxWidgets, but I aways find the instalation very confusing and dificult, so I never really installed it. The thing is, should I even bother at trying to do it? I mean, all I wanted was some kind of tool were I could build a windowed program without hard-coding all the buttons and such, but I never found a way to do this. Maybe wxWidgets was suposed to be it, but why can't I just download something that installs it for me? It just looks easyer to hard code my window then to install that thing.

Any toughts? Thanks!

[cprgmswr2]

I made a c++ program that has a visual basics interface and then it spits out all the source code so you don't have to hand code the coordinates. I have found though that no one seems to care for a program like that though. The program uses pure win32 API

[BigAngryDog]

>wxWidgets even worth it?

In my opinion, yes.

Admittedly, the install procedure could (and should) be improved. Initially, I had difficulties but put them down to my own inexperience and stuck with it. I now find it builds easily with both GCC/C:B and VC2005. But like most things, it's easy when you understand it, but for was really confusing at first.


>all I wanted was some kind of tool were I could build a windowed program without hard-coding all the buttons and such

In this case, perhaps, wxWidgets is not what you're looking for. wxWidgets is a C++ class library, and on its own, it is not a drag and drop design time GUI construction tool. There are projects around which intend to provide a Delphi-like IDE which will integrate with your C++ IDE, but personally, I find it easier (and more reliable) to hard-code my interface stuff.


>It just looks easyer to hard code my window then to install that thing.

With what? WinAPI/MFC? I believe it would be worthwhile working through your installation difficulties.

If you find it helpful, here is a link to my first wxWidgets project, which includes source code & documentation.

http://www.bigangrydog.com/celest/index.htm

IMHO if something is too easy, it ain't worth it. So, in short, yes, wxWidgets is worthwhile.

[Michael]

Well, several times I have tried to use wxWidgets, but I aways find the instalation very confusing and dificult, so I never really installed it. The thing is, should I even bother at trying to do it? I mean, all I wanted was some kind of tool were I could build a windowed program without hard-coding all the buttons and such, but I never found a way to do this. Maybe wxWidgets was suposed to be it, but why can't I just download something that installs it for me? It just looks easyer to hard code my window then to install that thing.

Any toughts? Thanks!

Hello,

Yes, may be the installation of wxWidgets is at the beginning not so easy, but after some search not so difficult (and you can always ask in the wxWidgets forum .

Using wxWidgets for simple task is not so time-consuming (and the wxWidgets book is available for free . Moreover, you can try wxSmith (C::B RAD plugin).

Sometime, I have used Qt Designer for the Qt library, which worked fine (at least for Qt version 3.x.x).

Best wishes,
Michael

[algumacoisaqq]

Well, thank you guys for the replying!

So I decided to try once more to compile it... but it just didn't worked.

First time, he says he can't find the mingw32-make in the build\msw directory. Ok, so I went into the mingGW\bin\ directory and typed that stuff

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1  clean

logically I replaced makefile.gcc with c:\wxWidgets\build\msw\makefile.gcc. It beginned compiling only to complain that
config.gcc: Nu such file or directory (but there was the file, I saw it!), and later complaining that
"mingw32-make *** No rule to make target 'config.gcc'. Stop."

Ok, so I comented out the config.gcc from the makefile.gcc. It now told me that he couldn't find the file \..\..\samples\
Ok, so I copied the mingw32-make.exe into the build\msw\ folder, so that he would at least find the correct directories. And then, after showing a bunch of stuff in the screen, he gave me the error that he couldn't found the mingw32-make command (I can't tell precisely what the error was because it was in Portuguese). So I give up.

I just don't get it... this is too damn ridiculously hard. What's the point with all that?

[vesselin_peev]

Do you have the MinGW bin directory in your path, e.g. C:\MinGW\bin? You need to have it in your path. Then, re-run the make command from the build\msw directory. And make sure that before doing that, you revert to the original, unmodified makefile.gcc.

[mandrav]

I just don't get it... this is too damn ridiculously hard. What's the point with all that?

Read this article (just the section 2.1.1,  about wxWidgets)...

[mandrav]

...or read this post by Thomas, again just the wxWidgets part.

[mdelfede]

........ or this very well explanation on wiki, that covers all from installing mingw to code::blocks from sources passing thru wxWidgets...... I found it near perfect  :shock:

http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows

Regards

Max

[algumacoisaqq]

Do you have the MinGW bin directory in your path, e.g. C:\MinGW\bin? You need to have it in your path. Then, re-run the make command from the build\msw directory. And make sure that before doing that, you revert to the original, unmodified makefile.gcc.

This is probably my problem, since I never knew how to deal with the 'path'. However, when I do:

Code

set path=c:\mingw\bin;c:\mingw\mingw32\bin
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0

It will still tell me that "mingw32-make is not recognised as a intern or extern command, an operational program or a file in 'lotes' " (don't know how to translate that).

About the articles... Some of them I've read, but it never worked.
Anyway, thanks you all for replying.

[mdelfede]

This is probably my problem, since I never knew how to deal with the 'path'. However, when I do:

Code

set path=c:\mingw\bin;c:\mingw\mingw32\bin
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0

Supposing that you have correctly installed mingw in c:\mingw, the most reliable (and permanent) way to put it in your path is done with these steps :
1) Open 'My Computer" in start menu (or whatever it's called in your language...)
2) Right click in 'My Computer' window, select "Properties" from menu
3) Select "Advanced" tab, then select the button right on top of Ok button (sorry, I've got Italian windows XP and don't remember the english label....)
4) In 'System Variables" (if I remember the english name...), select path and edit it, adding this at the end :

Code

            ;c:\mingw\bin;c:\mingw\mingw32\bin

try it, if it's ok, you should be able to run mingw32-make from all places.

btw, that's a trival thing in windows.... If you have problems with this, I guess it's only the beginning....

Ciao

Max

[algumacoisaqq]

Thanks mdelfelde! It compiled! Ito be honest, I don't really shure what to do now (didn't checked yet), but at least I know that I'm in the right track. Thanks!

[mdelfede]

Thanks mdelfelde! It compiled! Ito be honest, I don't really shure what to do now (didn't checked yet), but at least I know that I'm in the right track. Thanks!

Happy that this helped you 
We all had to start programming, and sometimes we forget our starting problems  :shock:

You could begin trying to compile some of the wxWidgets samples (i'm doing it right now), that's useful to see how they work.

Ciao

Max

[Angel Portal]

Well May some of you know something about Ultimate++, does it work on Code::Block

[thomas]

Well May some of you know something about Ultimate++, does it work on Code::Block

We don't directly support it (there is no template or anything), but there is no reason why you should not be able to use it with Code::Blocks.

Personally, I find the style of Ultimate++ scary (almost repulsive), but what they do is beyond any doubt valid C++, and it is certainly a lot more concise and more efficient than for example wxWidgets. If you can live with this particular coding style (which is a pure matter of taste), then Ultimate++ is a very good thing.

Ultimate++ works with gcc, and therefore you can use Code::Blocks to develop with Ultimate's toolkit (gcc is Code::Blocks' default compiler).
All you have to do is build the library (and create some application templates if you need any).

[Raijinsetsu]

Supposing that you have correctly installed mingw in c:\mingw, the most reliable (and permanent) way to put it in your path is done with these steps :
1) Open 'My Computer" in start menu (or whatever it's called in your language...)
2) Right click in 'My Computer' window, select "Properties" from menu
3) Select "Advanced" tab, then select the button right on top of Ok button (sorry, I've got Italian windows XP and don't remember the english label....)
4) In 'System Variables" (if I remember the english name...), select path and edit it, adding this at the end :

Code

            ;c:\mingw\bin;c:\mingw\mingw32\bin

try it, if it's ok, you should be able to run mingw32-make from all places.

You shouldn't really change the path to include those bin directories because CygWin and MinGW have DLLs that clobber some programs that use GTK in windows(Gaim, Gimp, etc.). Also, I noticed, at least on my system, that the stability of windows dropped a ton. Supposedly this was from my shell program using DLLs in CygWin's bin directories instead of in the programs working directory. This is really the problem of those other programs, but until those other programs start fixing themselves, I don't suggest changing the path variable in this manner.

[Michael]

You shouldn't really change the path to include those bin directories because CygWin and MinGW have DLLs that clobber some programs that use GTK in windows(Gaim, Gimp, etc.).[...]

Hello,

But if you have just MinGW, then there are no problems . Anway, each time I install MinGW (with the installer), the PATH env. variable is automatically updated (or the mingw bin path is added).

Best wishes,
Michael

[Raijinsetsu]

There are still problems, trust me, I've run into them. System stability dropped significantly. ANY program that uses a DLL in it's home directory that happens to have the same name as one in the cygwin\bin or cygwin\usr\bin directories will be clobbered. This applies for mingw also. Windows searches %PATH% for DLLs, then it searches the current working directory. Read what I wrote in another thread: http://forums.codeblocks.org/index.php?topic=3550.0

le meow

[Pecan]

DLL search order depends on your windows settings

DLL search path

DLL procedures are usually declared without giving a path to the DLL file. The normal Windows search order for a DLL is the following.

   1. Directory from which app loaded (executable directory)
   2. Current directory (can be overridden with an API call to SetDllDirectory)
   3. System directory
   4. 16-bit system directory
   5. Windows directory
   6. Directories listed in the PATH environment variable

What is more, WinXP and later have a setting where the current directory is searched only after the System and Windows directories.

Windows 2003 server SP1 changed the default search order to "paths first" to fight some trojans.

Dynamic-Link Library Search Order

Starting with Windows XP, the dynamic-link library (DLL) search order used by the system depends on the setting of the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode value.

    Windows Vista, Windows Server 2003, and Windows XP SP2:  The default value is 1.

    Windows XP and Windows 2000 SP4:  The default value is 0.

If SafeDllSearchMode is 1, the search order is as follows:

   1. The directory from which the application loaded.
   2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
   3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
   4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   5. The current directory.
   6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.

If SafeDllSearchMode is 0, the search order is as follows:

   1. The directory from which the application loaded.
   2. The current directory.
   3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
   4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
   5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.

There are also some legacy conditions for loading. Article is at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

[Raijinsetsu]

The "Registry"... just one of the many "benefits" of Winblows. And I think their search algorithm might be broken, because libraries in cygwin\bin were being used before application libraries, which, according to the article, is impossible.
Thanks for the post.

[mdelfede]

There are still problems, trust me, I've run into them. System stability dropped significantly. ANY program that uses a DLL in it's home directory that happens to have the same name as one in the cygwin\bin or cygwin\usr\bin directories will be clobbered. This applies for mingw also. Windows searches %PATH% for DLLs, then it searches the current working directory. Read what I wrote in another thread: http://forums.codeblocks.org/index.php?topic=3550.0

le meow

btw, with MINGW there's only ONE dll, and it's specific to mingw, so I think there's really no problem at all putting mingw in the path. Of course, if you have an executable with the same name of one in mingw tree, you'll have maybe the wrong one when you run it... but then, I think you have really a poor installation on you system.

Speaking about windoze, it's well known that it becomes slower and less stable with time, because of installation of new software, etc... but you'll not solve it taking mingw off the path.
The only way to keep window more or les performant would be e frash install, let's say, each year. I'm thinking to do it like this in my office, as all PCs that I've there are becoming unusable.
I'll make a complete fresh setup with all software I need, and then make a copy of system disk on DVD to spare installation time when i'll run again into problems (which is unavoidable, believe me...)

That's the first reason I'd like to migrate completely on Linux... at least, there you know (or CAN know) there to put your hands to solve problems without having to do a fresh installation.

Regards

Max