Thanks for the quick reply Albatross,
English is not my native language,so I may have used a wrong word as "to be forced".What I mean is,in many replies (this forum and others) I see something like "get rid of DevC++ (and wxdevc++,too)".Thats why Im looking for a way to switch to Code::Blocks.
I have just finished the document you suggested,and learnt some basics about code::blocks.
Now , can you suggest a beginner document for using wxwidgets with C::B ?
I think wxSmith is for this purpose.
Those with slow connects trying to download Code::Blocks for Windows; I suggest using the sourceforge site and a download manager like getright http://getright.com/.
I would like to also add another good IDE to the list as an alternative to DevC++
Nokia's QT Creator is an excellent alternative as well. Although it is specifically aimed at creating QT applications, it works with MinGW and you can very easily set it up to compile any kind of C++ project given that your libs are correctly linked and your dependencies are satisfied (as with any IDE). When installing on Windows, it sets everything up automatically for you (including the compilers you need).
I use Visual Studio on Windows, but on Ubuntu I use QT Creator because it is a very user-friendly IDE and it has just about everything a C++ dev needs.
Using a basic text editor and terminal is not too hard if you use a program such as 'make' to automatically recompile and link edited files. A shell or batch script works too, but with make many file projects will build faster and you can have more control over the executable(release, test, package files up, etc).
Learning make's syntax is slightly tricky, writing only a simple makefile is quite quick (plenty of resources on google).
Even making a makefile for a more complex library isn't that bad, as long as you remember to update it with your project so you don't end up behind on work. ;)
Chucking in my own views on makefiles, at work I have a makefile that has evolved into understanding the differences between library and executable, release and various levels of debug, and a few other bits and pieces.
The convenience of being able to skip between library/executable/debug1/debug2/release etc is as easy as:
make sample
make sample debug
make sample debug2
make sample library-debug
make sample library-release
and various others. One line to type, and the relevant version gets built, copied into the right place dependent on which version it is, libraries dumped into the directories as needed for test-running and that sort of thing.
When I use an IDE now and have to go through a few menus to change settings, even though is only takes 30 seconds in a compile cycle than might last three or four minutes, I still find myself getting angry with the delay. I know what I want to do, I want to just type it!
At one point I set up a system wherein I had a Templates folder, Source folder, Objects folder and Binary folder, all within my Projects folder. I then wrote a Makefile that could add new projects (make a directory in each folder (except Templates), copy a template Makefile (either Template/Makefile.library or Template/Makefile.program), README file, COPYING file (license specified on the command-line) and Doxyfile. Then it would copy the name of the project into each file (to replace something like "$PROJECT"; I used shell scripts for this part)), compile, build, "release" (create a zipped archive of the entire project; could be bzip2, gzip or lzma), release-source (archive source only), release-bin (archive binaries only), install, clean (remove object files) and "ocdily-clean" (remove everything except the source files, README files, etc.).
I quickly got rid of it because I liked having a different directory structure for each project and because I thought it would make programming with other people or working on other people's projects difficult. I'm thinking of going back to it, and then either writing a script to convert the directory structure of other people's projects to my own (edit: and vice versa), or (more likely) having a separate directory for non-conformant projects.
Huh? Doesn't the IDE you use support multiple build targets? (ehh, and most IDE's support makefiles anyways).
Well no - I don't use one. However, the last time I did use one, it did, and I found it not as easy and convenient as makefiles. It's too slow and painful to set them all up, compared to a makefile. Also, I find that when I'm in a deep code cycle, with various terminals open, once I've done a few iterations, all the commands are stacked in the terminal history and a complete set of everything involves pressing (for example) [UP-ARROW UP-ARROW UP-ARROW, ENTER] three times in the space of a three seconds,and then leaving it to get on with things. These thigns can be automated in an IDE, but compared to automating it with makefiles it's like wading through syrup.
Also, there are a lot of things the IDE still struggles to do for me; the makefile can trigger bash scripts (or indeed, be triggered by bash scripts); also, the chaining of makefiles across projects is lovely (I commonly use it to rebuild libraries I'm not even working on at the time, so I can drag in latest versions of various other things - having to open a half-dozen projects on an IDE to do that really gets to me - even though it would just take a couple of minutes to do each one, knowing I could do it all in seconds with a few typed commands makes doing it by IDE really irritating). Obviously these things don't annoy others as much, hence other people using IDEs. It's all personal preference.
Also, the makefile is fabulously portable and cross-platform; everything I build at work these days is cross-platform, and plain text makefiles have proven themselves to really be the most cross-platform option we could find.