The 27 July 2009 build (5716) is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc421.7z

The 27 July 2009 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20090727_rev5716_win32.7z
  - Linux :
   none

Resolved Fixed:

• BrowseTracker 1.2.80 2009/07/22
  - Call OnEditorActivated() from OnEditorOpened() because editors actived by Alt-G, "Swap header/source", and "Recent files" have no cbEditor associated in EVT_EDITOR_ACTIVATED, and GetActiveEditor() returns NULL.
  - Hack to find editor's project. Since wxAuiNotebook, the initial EVT_EDITOR_ACTIVATED has no cbEditor or cbProject associated.
  
• make indendation-guide be shown in empty lines too, thanks to ollydbg
• brace completion [applied patch 2746 ]
• added missing properties in editorcolourset's copy constructor
• fixed a crash-candidate; corrected HitTest in switcher-dialog
• added version-guards for wxAuiToolbar in wxSmithAui, because it was added to wxWidgets in 2.8.9 and breaks build on some distros
• avoid underlinking of wxSmithContribItems
• precompile sdk.h, otherwise debugging on linux is partly broken if gcc >= 4.3, see http://forums.codeblocks.org/index.php/topic,10529.msg73835.html#msg73835
• fixes for ThreadSearch to use C::B's encoding-detection
• (nasty) hack to avoid a name-conflict between wxWidgets GSocket and the one introduced in glib 2.21

Regressions/Confirmed/Annoying/Common bugs:

[Xaviou]

Ubuntu 8.04 to 9.04 Amd64 tar.gz archive (containing '.deb' installers builds with wx2810) can be found  here (direct link).
".mo" files for french translation can be founded here (see below for installation instructions)
Full Win32 French Version (including wxWidgets and MinGW dlls and french ".mo" files) can be founded here

Installing french files:

• under Linux : put these files in /usr/share/codeblocks/locale/fr_FR/ (you'll have to create these folders the first time)
• under Windows : put these files in $CodeBlocks_Install_Dir\share\CodeBlocks\locale\fr_FR\ (you'll have to create these folders the first time)

Regards
Xav'

[jens]

Just moved the debian-build on my server (see signature) into the repo.

They are build on lenny-pbuilder and linked against wxWidgets 2.8.10.

[ahui886]

thx

[Loaden]

Have a question, i hope CB term can fix it. Thanks!

[MortenMacFly]

Have a question, i hope CB term can fix it. Thanks!

If you mean "team" by "term" the it's "fixed" (probably better to say adjusted) in trunk.

[Loaden]

Have a question, i hope CB term can fix it. Thanks!

If you mean "team" by "term" the it's "fixed" (probably better to say adjusted) in trunk.

Oh. god.
Sorry for my poor english.
I build SVN5717, this question is gone!
thanks!

[Loaden]

I have a question: on the compiled information, as when using GCC 4.
I hope the CB development team can fix it, thank you!

In the 'Start here' page of the information displayed:

svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicode

The time format is wrong.

[vix]

I found a problem in File Encoding, running C::B under WinXP SP3: C files containing western characters like è, é, ò, ... aren't displayed correctly.
You can simply reproduce the problem if you create a new C file with the following content

Code:

hello èé

and save it as foo.c with File encoding >> System default (that is 1252 under WinXP),
After you close and re-open it inside C::B you should see

hello ий

The two western characters with ASCII codes 0xE8 and 0xE9 aren't displayed correctly.

If you force the encoding to System default, an Encoding Changed popup appears in the bottom right corner of the display

[trdm]

try 5716-svn:

[MortenMacFly]

svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicode

That's not wrong, that's exactly how SVN reports the date/time. It's just "a" format. Check any "entries" file in a .svn sub-foldr if you like. It's all the same.

[jens]

svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicode

That's not wrong, that's exactly how SVN reports the date/time. It's just "a" format. Check any "entries" file in a .svn sub-foldr if you like. It's all the same.

We parse the date with a regex, if we use automake on linux.

We can do something similar on windows (of course without regexes).
Any objections against this patch:

Code:

Index: autorevision.cpp
===================================================================
--- autorevision.cpp (Revision 5716)
+++ autorevision.cpp (Arbeitskopie)
@@ -122,6 +122,8 @@
             if(d && d->GetText())
             {
                 date = d->GetText();
+                date.replace(date.find('T'),1," ");
+                date.resize(date.find('.'));
             }
             return 1;
         }

[MortenMacFly]

We parse the date with a regex, if we use automake on linux.

Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?

[jens]

We parse the date with a regex, if we use automake on linux.

Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?

I know that he is talking about windows.

I don't know, why subversion uses this format for date/time of last commit (internally), but are there any objections against using a format, that's (better) human-readable for the date and time ?

The only cause would be, if we have to distinguish between to revision, that came in at the same second, but we also use the revision-number, so I don't see any problem.
And I don't think the patch to autorevision.cpp can break anything, unless the svn date-format changes.

[Biplab]

We parse the date with a regex, if we use automake on linux.

Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?

I know that he is talking about windows.

I don't know, why subversion uses this format for date/time of last commit (internally), but are there any objections against using a format, that's (better) human-readable for the date and time ?

The only cause would be, if we have to distinguish between to revision, that came in at the same second, but we also use the revision-number, so I don't see any problem.
And I don't think the patch to autorevision.cpp can break anything, unless the svn date-format changes.

Better consult with Thomas first. Once I wanted to fix this issue. But he didn't want to touch that code. I forgot the exact objection.