The 22 february 2006 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 22 February 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060222_rev2061_win32.7z
  - Linux : not supported yet


Resolved Fixed:

• Added editor setting for the default encoding when opening files
• Patch #845 : Fixes for compiling on FreeBSD 6.0
• Patch : Add "Additional paths" double-click editing
• Completely removed _U() and _C() macros. For new code use the functions cbC2U() and cbU2C() respectively
• Updated various readme files in the project's root directory

Regressions/Confirmed/Annoying/Common bugs:

• DDE bug : clicking in windows explorer on a CB registered file throws an error message box
• toolbar-images-not-changing-state (is a wx problem)

[killerbot]

off topic (so please do not discuss this), just as a gift to make you smile :
M$ has the largest error message with DirectX :
http://www.networkworld.com/community/?q=node/4630

[MoonKid]

I tried to run this build on my Win98se. I got the mingw10.dll and the wx*.dll.

It does not work.
The message is: "Die Datei CODEBLOCKS.DLL ist verknüpft mit dem fehlenden Export-SHELL32.DLL:SHGetFolderPathW.".
translated: "the file CODEBLOCKS.DLL is linked with the missing Export-SHELL32.DLL:SHGetFolderPathW.".

[TDragon]

The official C::B build is still missing a link to libshfolder.a, which corrects this issue for Win98 users (shell32.dll on Win98 doesn't have all the functions that is does on 2000/XP).

Anyway, if you got "CB_20060222_rev2061_win32.7z", it's a uncode build, so you would need to have the unicows library installed or you still won't be able to run it.

If you like, I can temporarily upload my latest nightly ANSI build which should at least run for you without DLL errors -- although Code::Blocks doesn't get much testing on Win98, so who knows what issues it might have. Give me a buzz.

[MoonKid]

yes, it would be gread. thx

[Jorg]

When will the official release be out for the next version?

With regards,
- Jorgen

[orefa]

Using nightly build versions of CB (not just today's version) I need to manually save my .h files before a compile. I cannot find a setting to do this automatically like RC2 does so I don't know if it's a bug, if I'm blind, or just generally troubled...  :?

[sethjackson]

When will the official release be out for the next version?

With regards,
- Jorgen

http://forums.codeblocks.org/index.php?topic=2372.0

[killerbot]

Using nightly build versions of CB (not just today's version) I need to manually save my .h files before a compile. I cannot find a setting to do this automatically like RC2 does so I don't know if it's a bug, if I'm blind, or just generally troubled...  :?

are these headers part of the project (so they show up in the project tree) ?? or are they include in project code, but the header is actually not specified in the project itself ??

[killerbot]

I tried to run this build on my Win98se. I got the mingw10.dll and the wx*.dll.

It does not work.
The message is: "Die Datei CODEBLOCKS.DLL ist verknüpft mit dem fehlenden Export-SHELL32.DLL:SHGetFolderPathW.".
translated: "the file CODEBLOCKS.DLL is linked with the missing Export-SHELL32.DLL:SHGetFolderPathW.".

Here is a link to the most recent one I think (ansi build, so for win9x) :
http://download.berlios.de/codeblocks/CB_20060217_rev2025_win32_ansi_.7z

I will create a new one on saturday.

[orefa]

are these headers part of the project (so they show up in the project tree) ?? or are they include in project code, but the header is actually not specified in the project itself ??

They are part of the project. Headers that are not listed in the tree would not be saved even in the RC2 version, but now it does not seem to matter if they are in the project or not, they are not saved when the corresponding .cpp file is compiled. They are saved when the full project is build. It's only with compilation of an individual .cpp file that it's a (lesser) problem, but still a bit annoying.

[TDragon]

Sorry it took me so long to get back (issues with corporate website and a DNS server), but here are:
cb-ansi-20060223-r2062.zip from this morning's build, and
wxmsw26_gcc_custom.zip from whenever I last built wxWidgets.

[killerbot]

are these headers part of the project (so they show up in the project tree) ?? or are they include in project code, but the header is actually not specified in the project itself ??

They are part of the project. Headers that are not listed in the tree would not be saved even in the RC2 version, but now it does not seem to matter if they are in the project or not, they are not saved when the corresponding .cpp file is compiled. They are saved when the full project is build. It's only with compilation of an individual .cpp file that it's a (lesser) problem, but still a bit annoying.

ok, that could be, yesterday O tried it myself and it worked well, but I builded a project. Not just a single .cpp file.
Well, we have different angles of view at this :
1) I have adjusted my file1.h and I want to compile my test2.cpp which does NOT include, (also not through other headers) file1.h  -> do I really want to have file1.h saved, maybe it is not even in a state where it would compile cleanly ( this argument can also be applied on project build, so I think it is a weak argument, certainly on project level) ??
When you build a project, it checks all files belonging to the project to see if they need saving

2) I have adjusted file1.h and file1.cpp (which in includes file1.h) is going to be compiled, (this is the case you say it does not save it (I did not check this yet)) -> would be nice to save it, we need to break this up in several sitations :
 - both files belong to the project (so the regular project search can be used -> easy)
 - the header files does not belong to the project, could check all include paths for modified files, this will sure make everything much slower, don't like it, so no more info on this one ;-)
 - the cpp file does not belong to the project (header can or can not belong to it), then there's no project to have it's files checked (could check the local directory where the file resides, but here also, don't like it ...)

So in my personal opinion, the situation where both belong to the project, it might be a good addition to have a 'project'-check for files to save action.

I will try to have a look at this, this weekend.

[orefa]

- both files belong to the project (so the regular project search can be used -> easy)
[...]
So in my personal opinion, the situation where both belong to the project, it might be a good addition to have a 'project'-check for files to save action.

I will try to have a look at this, this weekend.

Yes, this is exactly right. It's the only case of single-file compilation where a check would be both expected and convenient. Thanks for looking into it!

[boaz]

I'm not sure if this is old problems or not

1. symble search - Go to the symbles tab put a search term like "WXDLLIMPEXP_XML" press "-->". Boom C::B will crash.
OK I rechecked this happens only when you have files with ..\..\ type paths in your project (see below) once I have C::B compiling again I'll try to fix it.

2. Breakpoints Dialog - No remove, no right-click no nothing a list and thats it. Now looking in the code (SVN from 22/2/2006) for "breakpointsdlg.cpp" I see all these things in code. what plugin was included in the build?

If At it I have some Questions:

1. a C::B project for wxWidgets - I try to build an external make project for the <WX>\build\makefile.gcc. Now since I can't specify a working folder for the Make command, and since I don't even want to begin on adding Files to a project from ..\..\ folders. (Try right-click "open #include <wx/wx.h> " for just the begining of the problems with that). So I made a msw.Makefile at root folder that with an m.bat will run the build/msw/makefile.gcc, on all the right targets.
This all works well but on the Build-Messages the paths to compilation errors/warnnings are of the form "../../include/wx/log.h" : 55. Needless to say that C::B has hard time finding the files on double click.
Is there a switch to GCC that tells it to output full-paths to files instead of relative paths. I was looking in gnuc.org but could not find anything.