The 07 October 2012 build (8438) is out.

[gd_on]

There is a problem with the last update of fortran project plugin (rev 26).
It compiles but does not link correctly.
I think some files are missing in FortranProject_cbsvn.cbp, for windows.
If I compare with FortranProject_unix_cbsvn.cbp I think 3 files are missing in FortranProject_cbsvn.cbp :
      <Unit filename="lineaddress.cpp" />
      <Unit filename="resources\changecase.xrc" />
      <Unit filename="submoduletokenf.h" />
after adding them in FortranProject_cbsvn.cbp, it works now.

gd_on

[stahta01]

There is a problem with the last update of fortran project plugin (rev 26).
It compiles but does not link correctly.
I think some files are missing in FortranProject_cbsvn.cbp, for windows.
If I compare with FortranProject_unix_cbsvn.cbp I think 3 files are missing in FortranProject_cbsvn.cbp :
      <Unit filename="lineaddress.cpp" />
      <Unit filename="resources\changecase.xrc" />
      <Unit filename="submoduletokenf.h" />
after adding them in FortranProject_cbsvn.cbp, it works now.

gd_on

I believe you need to report that to the Fortran project site; not to CB.

Edit: I think this is the project URL http://darmar.vgtu.lt/

http://code.google.com/p/fortranproject/

Tim S.

[dk]

You simply have to enable localisation in the settings and select you language. Once this is done its persisted. This is what we had in mind: Start C::B w/o localisation at first run, let the user decide if and what to localise and remember that.

Yes, I see. But because I am the maintainer of codeblocks package in the russian distribution ALT Linux, it is important to start Code::blocks with russian translation "out of the box". There are no issues like "right-to-left text issue" in russian localization, and it is important to run Code::Block localized at the first run. There is a lot of users in the schools (pupils and teachers), it is not easy to them to run english codeblocks and after that change preference to turn on russian localization.

[rickg22]

I'm noticing another problem... is it just me, or projects opened with this version of C::B take much longer to open and update? 10 to 30 seconds opening, and with Code Completion completely disabled.

[MortenMacFly]

There is a lot of users in the schools (pupils and teachers), it is not easy to them to run english codeblocks and after that change preference to turn on russian localization.

Well you could add/provide a default config file that has just the localisation part as a work-around. would that be an option?

[MortenMacFly]

I'm noticing another problem... is it just me, or projects opened with this version of C::B take much longer to open and update? 10 to 30 seconds opening, and with Code Completion completely disabled.

Compared to what version? As you know we are discussing related stuff (concerning computation of the CommonTopLevelPath) in another thread...

[Pchief]

I have recently redone a build process thoroughly. This includes:

(1) removing all my old files (including all c::b-installation files, downloaded c::b svn sources, MinGW install files, Wxwidget sources and output files)
(2) re-installing MinGW from scratch
(3) downloading wxWidget-2.8.12 sources and re-build them from scratch (following wiki instructions with no compilation error)
(4) downloading and installing this nightly-build of c::b (which works fine)
(5) doing a checkout of latest c::b svn sources from scratch
(6) building c::b and its contrib-plugin workspaces (following wiki instructions with no compilation error)
(7) uninstalling this nightly-build of c::b replacing it with the newly built version (following wiki instructions)

...and the doxyblocks plugin still causes crash. What's more, no codeblocks.RPT was even generated this time.

[MortenMacFly]

...and the doxyblocks plugin still causes crash. What's more, no codeblocks.RPT was even generated this time.

If you have C::B compiled yourself anyways, why don't you tray to debug into the code to help?

I'll try myself, but I rarely use DoxyBlocks these days (all my projects are properly setup).

[rickg22]

I'm noticing another problem... is it just me, or projects opened with this version of C::B take much longer to open and update? 10 to 30 seconds opening, and with Code Completion completely disabled.

Compared to what version? As you know we are discussing related stuff (concerning computation of the CommonTopLevelPath) in another thread...

I'm not sure, it's probably the previous version (I installed C::B recently on my new job's machine). I'll report back tomorrow. Meanwhille, I'll search for that CommonTopLevelPath thread you mentioned.

[rickg22]

OK, about that thread... is it this one?

http://forums.codeblocks.org/index.php/topic,15423.0.html

Anyway, I ran codeblocks.exe -d and this is what I got:

Code

Top Editor: C:\htdocs\SIG\SGPG\js\app\controllers\comercializacion\InitPanelGrid.js
(here comes the several seconds pause)
EnvVars: Obtained 'default' as active envvar set from config.

Another difference between work and home computer is that at work I have Windows 7 64-bit, while at home I have Windows 7 32-bit. I doubt that's it, but I mentioned just in case. Oh - the slowdown also happens when I change ANY settings under "Project Tree", like "display folders as on disk".

[rickg22]

OK, I checked, and at work the 8248 revision is still fast when opening projects.

[dk]

There is a lot of users in the schools (pupils and teachers), it is not easy to them to run english codeblocks and after that change preference to turn on russian localization.

Well you could add/provide a default config file that has just the localisation part as a work-around. would that be an option?

Is it a way to make a system default config file, that will be used if no user config exists?
Or you mean, that I should create /etc/skel/.codeblocks/default.conf as a default config for all new users?

[MortenMacFly]

Or you mean, that I should create /etc/skel/.codeblocks/default.conf as a default config for all new users?

This is what I had in mind. Apologies - I am not a Linux expert, but to my (maybe limited) knowledge this should be possible. Maybe more Linux-oriented devs can comment.

[rickg22]

OK, I checked, and at work the 8248 revision is still fast when opening projects.

Update: I just reinstalled 8248 at home (with the most recent wxWidgets dll) and it's still slow. I'm lost, why can the same program be slow in one machine but fast in another?

[MortenMacFly]

When a document is open, selecting most items of the DoxyBlocks Menu(e.g. block comment, line comment, run chm, ...) leads to crash.

This will be fixed in the next nightly.