The 11 November 2009 build (5911) is out.

[ebiber]

Hi, I download a patch from http://mmkider.googlepages.com/wxmsw28u_gcc_cb_wx2810.7z (found on http://forums.next.codeblocks.org/index.php/topic,10406.msg71815.html#msg71815 ) and with this patch I cannot reproduce the crash, toolbox can be detached.

regards,
enis

[Xaviou]

Ubuntu 8.04 to 9.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx2810 from wxWidgets's repository) 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'

[gd_on]

@killerbot or an other admin :
I have found a small typo in wxsmith, in wxsglcanvas. At line 114, I think it should be :
"GLCanvasAttributes", not "GLCanvasAttribuets"

@xaviou
I see a post above that you have a French translation for C::B. Nice thing, of course. I myself put several times .po and .mo files available in a specific thread for Translation and was ready to update it with some new translated strings. I'm a little bit frustrated because if you have made some improvements in the translation files, it could have been a good idea to share this work. But it's not easy with only .mo files. I have also recognized some of my own old typos by reverse engineering a few of your .mo files, typos that have been corrected now quite a long time ago. You have made the choice to have several .mo files, I prefer a monolithic .mo, but this is not really the problem. I'm not the official French translator, I know that. Many people have contributed and shared work in launchpad some time ago. It's also true that launchpad version is too outdated to be usable. Nevertheless, it could be a good idea to share the work as I asked in my last post.

gd_on

[killerbot]

"GLCanvasAttributes", not "GLCanvasAttribuets"

Thanks, I will fix this.

[Xaviou]

@xaviou
I see a post above that you have a French translation for C::B. Nice thing, of course. I myself put several times .po and .mo files available in a specific thread for Translation and was ready to update it with some new translated strings. I'm a little bit frustrated because if you have made some improvements in the translation files, it could have been a good idea to share this work. But it's not easy with only .mo files. I have also recognized some of my own old typos by reverse engineering a few of your .mo files, typos that have been corrected now quite a long time ago. You have made the choice to have several .mo files, I prefer a monolithic .mo, but this is not really the problem. I'm not the official French translator, I know that. Many people have contributed and shared work in launchpad some time ago. It's also true that launchpad version is too outdated to be usable. Nevertheless, it could be a good idea to share the work as I asked in my last post.

I didn't thought about sharing ".po" files, I'm sorry.
I've just updated the zip file.

And for ubuntu, pasgui has made a supplementary package to include french translation.
Ubuntu users just have to install the "codeblocks-fr" package, and activate the i18n option.

@gd_on : my extracting tool is made from yours, so if you want something else than ".po" files, don't hesitate to ask for it...

Regards
Xav'

[gd_on]

Hi,
here a problem not concerning translation ...
I'm triing to build SVN version 5919 on two linux machines. On the first one, all is OK but on the second one I obtain a compilation error.
The first machine uses Redhat 4.7, gcc 4.1.2-42 and wxWidgets 2.8.7 (here OK)
The second one uses CentOS 5.3, gcc 4.1.2-44 and wxWidgets 2.8.9.
Here is the error log at compilation :

Code Select Expand


||=== Code::Blocks - Unix, scintilla ===|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx||In function 'char** ArrayFromWordList(char*, int*, bool)':|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|585|warning: array subscript has type 'char'|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|586|warning: array subscript has type 'char'|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|588|warning: array subscript has type 'char'|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|589|warning: array subscript has type 'char'|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx||In member function 'bool WordList::InList(const char*)':|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|678|warning: array subscript has type 'char'|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx||In member function 'bool WordList::InListAbbreviated(const char*, char)':|
/home/durand/CodeBlocks_SVN/CodeBlocks_src/trunk/src/sdk/wxscintilla/src/scintilla/src/PropSet.cxx|740|warning: array subscript has type 'char'|
||=== Code::Blocks - Unix, sdk ===|
/usr/include/wx-2.8/wx/filename.h|393|error: ambiguous overload for 'operator[]' in 'wxFileName::GetPathSeparators(wxPathFormat)()[0u]'|
/usr/include/wx-2.8/wx/filename.h|393|note: candidates are: operator[](const wxChar*, long int) <built-in>|
/usr/include/wx-2.8/wx/string.h|822|note:                 wxChar& wxString::operator[](int)|
/usr/include/wx-2.8/wx/string.h|824|note:                 wxChar& wxString::operator[](size_t)|
||=== Génération terminée : 1 erreurs, 6 avertissements ===|


Looking in string.h, it may be because wxSIZE_T_IS_UINT has been defined somewhere. But why on the second machine, not on the first one!
I'm not admin on both of those machine, so I can't modify many things (only on my own folder). Just trying a few things, and, if it works, trying to convince an admin to do some jobs for me ...
I have found a workaround : if I transfer the content of the output folder from my first machine to the second one, my codeblocks works, but I would prefer to do all the job on the second one. Redhat 4.7 and CentOS 5.3 seems to be highly compatible in that case, but ...

Thanks

Gd_on

[gd_on]

An other small problem with last svn release 5923.
file "update" in trunk/src is apparently saved in Windows text format (with cr/lf).
On my linux machines, it does not work. Must be converted to unix format (lf only).

gd_on

[Jenna]

An other small problem with last svn release 5923.
file "update" in trunk/src is apparently saved in Windows text format (with cr/lf).
On my linux machines, it does not work. Must be converted to unix format (lf only).

gd_on

Are you absolutely sure ?

I just deleted update and started an svn update to fetch a "fresh" one, and it does not contain any cr-lf

[gd_on]

Yes I am.
I don't know why, but the "update" file I have received from svn (updated with tortoise svn 1.6.5) contains cr/lf, so in windows format.

gd_on

[stahta01]

Yes I am.
I don't know why, but the "update" file I have received from svn (updated with tortoise svn 1.6.5) contains cr/lf, so in windows format.

gd_on

The "svn:eol-style" is "native" on "update" so it will adjust to the system default line ending.

Tim S.

[gd_on]

You are certainly right. And my svn runs on Windows, then I port the result on Linux, not connected to Internet. But it's the first time this happens like that and this update file is the only one with cr/lf inside. There are 3 or 4 other update file in contribs folders, all with lf alone.
Nevertheless, the workaround is very simple.

gd_on

[oBFusCATed]

gd_on: Do you know that the file structure generated by svn is not compatible between OSes? (It is written somewhere on their site)

[gd_on]

No, I don't.
Nevertheless, It worked quite well until last changes. And I haven't any linux machine connected to Internet.
So never-mind, I will continue and correct some files if needed.

gd_on

[stahta01]

Patch needed for NOPCH compile under Windows 6.1 (AKA Windows 7).

Tim S.

Code Select Expand


Index: src/sdk/projectfileoptionsdlg.cpp
===================================================================
--- src/sdk/projectfileoptionsdlg.cpp (revision 5925)
+++ src/sdk/projectfileoptionsdlg.cpp (working copy)
@@ -12,6 +12,7 @@
#ifndef CB_PRECOMP
    #include "cbproject.h"
    #include "compilerfactory.h"
+    #include "logmanager.h"
    #include <wx/xrc/xmlres.h>
    #include <wx/intl.h>
    #include <wx/choice.h>


My understanding id that sdk_precomp.h is to be used inside SDK only; everywhere else should use sdk.h.

Code Select Expand


Index: src/plugins/contrib/CppCheck/CppCheckListLog.cpp
===================================================================
--- src/plugins/contrib/CppCheck/CppCheckListLog.cpp (revision 5932)
+++ src/plugins/contrib/CppCheck/CppCheckListLog.cpp (working copy)
@@ -1,4 +1,4 @@
-#include "sdk_precomp.h"
+#include "sdk.h"

#ifndef CB_PRECOMP
     #include <wx/arrstr.h>


[godlike]

I created a build target for Intel's C++ compiler. The project builds just fine but there is a problem with the settings.

I go to: "project build options" -> I select my target -> "compiler settings" tab -> "other options" tab

I put a custom ICPC flag but it never saves it. When I click ok and then go again its lost.

If it is a bug please tell me if I should submit.
Thanks in advance and great work with C::B. Im using it for almost 2 years now.


Edit: I forgot to mention that Im using the 64bit debian version from jens repository