The 01 october 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://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z

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

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

The 01 October 2006 build is out.
  - Windows : http://prdownload.berlios.de/codeblocks/CB_20061001_rev3002_win32.7z
  - Linux :
         http://prdownload.berlios.de/codeblocks/CB_20061001_rev3002_Ubuntu6.06.deb
         http://prdownload.berlios.de/codeblocks/CB_20061001_rev3002_fc4+5.rpm (not yet)


Resolved Fixed:

• search in files : result set in message pane : only double click to open editor containing that result (allows to key navigate in the result list without opening all those editors)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• menu items with icon not correctly aligned (since wx263)

[BigAngryDog]

Good job on the file search.

Just one more teeny teeny teeny suggestion...

When a string is found in one or more files, C::B seems to open the first in the results by default.

Would it not make sense to not open any file by default if there are more than one files found containing the search string? Or perhaps don't open any file at all until the user double clicks a result. I say this because C::B does not know which file the user wants to open/examine where there are multiple [file] matches.

Just a thought.

[sque]

There is a bug in codecompletion with namespaces... I don't have done an extended test but I think I am right.

Ok, now the bug. If you create a file testa.h with some code

Code: cpp

// FILE: testa.h
#include "MySpace.h"
using namespace MySpace;

// << Here the code completition will see all the classes inside MySpace.

Now, at a new file (let's say testb.h) include testa.h.

Code: cpp

// FILE: testb.h
#include "testa.h" // << THIS FILE HAS INSIDE: using namespace MySpace

// << Here the code completition will see NONE of the MySpace classes, although you are using the namespace as declared at testa.h

/*
bla bla bla
*/

using namespace MySpace; // Ok we redeclare it
// << From this point CC will work fine with MySpace members.

With a sort description, I think that CC doesn't calculate "using namespace" from recursive includes.
I am using 25th September build (r2995)
Please someone else validate that this bug exist. I don't wont to file an invalid bug

[killerbot]

actually it is correct, as long as you don't say using namespace MySpace; the functions are not in the scope of the compiler (yes, saying compiler here, because it's c++ feature). In such a case you have to specifcy manually like : std::cout.  So more or less it's a good thing the CC is also hiding it.

[killerbot]

Good job on the file search.

Just one more teeny teeny teeny suggestion...

When a string is found in one or more files, C::B seems to open the first in the results by default.

Would it not make sense to not open any file by default if there are more than one files found containing the search string? Or perhaps don't open any file at all until the user double clicks a result. I say this because C::B does not know which file the user wants to open/examine where there are multiple [file] matches.

Just a thought.

it's on my todo list, but first gonna check some other IDE's first to see what they are doing, just to get a feeling.

[sque]

actually it is correct, as long as you don't say using namespace MySpace; the functions are not in the scope of the compiler (yes, saying compiler here, because it's c++ feature). In such a case you have to specifcy manually like : std::cout.  So more or less it's a good thing the CC is also hiding it.

Sry I didn't understand :shock: (no offend, just my english isn't that good)...  Is there a specification that says "using namespace" has effect only in the scope of file that is declared? Because at least with gcc, that isn't true. You can include other files that specify "using namespace" and this have effect at the end-file too.

[mandrav]

Sry I didn't understand :shock: (no offend, just my english isn't that good)...  Is there a specification that says "using namespace" has effect only in the scope of file that is declared? Because at least with gcc, that isn't true. You can include other files that specify "using namespace" and this have effect at the end-file too.

No, there's no such specification. It's just that adding "using namespace" inside header files is considered bad practice. Think about it: if you do that in a header then all files including it, directly or (god forbid) indirectly, will be using that namespace too. This is namespace littering and is what namespaces were invented to avoid .

CC doesn't parse included files for "using namespace" keywords.

[sque]

No, there's no such specification. It's just that adding "using namespace" inside header files is considered bad practice. Think about it: if you do that in a header then all files including it, directly or (god forbid) indirectly, will be using that namespace too. This is namespace littering and is what namespaces were invented to avoid .

CC doesn't parse included files for "using namespace" keywords.

Yeah, probably you are right about my programming tactics, and maybe I 'll change them. But its different what should everyone do and what the compilers can do. What am I saying is, if compilers DO parse recursively for "using bla bla", why CC must be limited?
In my opinion it should be parsed, although I may never use it in the future as your arguments where good enough

[mandrav]

Yeah, probably you are right about my programming tactics, and maybe I 'll change them. But its different what should everyone do and what the compilers can do. What am I saying is, if compilers DO parse recursively for "using bla bla", why CC must be limited?
In my opinion it should be parsed, although I may never use it in the future as your arguments where good enough

I am not criticizing your programming practices. Anyway, CC doesn't parse "using" directives in the parsing stage because it would add unnecessary complexity in the parsing process. Not that it's impossible, it just would add a lot of complexity. I chose to leave this out and concentrate on more important things/bugs instead. It might be added/fixed sometime in the future but I wouldn't hold my breath .

[sque]

Ok I understand. So I 'll file it at the bugzilla, just to not be forgotten in the future.

[BrianSidebotham]

Hi There,

Is it possible to save the file highlighting information from the edit menu options in the c::b project?

At the moment, it's nice to have my makefile syntax highlighted, but I have to manually set the highlighting every time I open the project.

Best Regards,

Brian Sidebotham.

[sethjackson]

Hi There,

Is it possible to save the file highlighting information from the edit menu options in the c::b project?

At the moment, it's nice to have my makefile syntax highlighted, but I have to manually set the highlighting every time I open the project.

Best Regards,

Brian Sidebotham.

Hmm does your makefile have an extension? Like .mak? Or is it named Makefile?? A lexer is applied to a doc based on the extension AFAIK. So if your makefile doesn't have something like a .mak extension then you will have to manually set it every time.

[Jan van den Borst]

Hello all,
I experience some troubles for quite some time now regarding windows shutdown and codeblocks crash. When I shutdown my computer and codeblocks is still running, codeblocks always crash even when you are prompted to save your work. Saving works but codeblocks crashes afterwards. No problem closing codeblocks normally (not forced by a windows shutdown)
Any ideas?
Jan

[BrianSidebotham]

Hmm does your makefile have an extension? Like .mak? Or is it named Makefile?? A lexer is applied to a doc based on the extension AFAIK. So if your makefile doesn't have something like a .mak extension then you will have to manually set it every time.

It has no extension. The setting is manual, from the Edit menu, and you can apply anything you want to a file with an 'unrecognised' extension. If the extension is unrecognised, it would be beneficial for c::b to remember any highlighting information for that file in the cbp

[takeshimiya]

Hmm does your makefile have an extension? Like .mak? Or is it named Makefile?? A lexer is applied to a doc based on the extension AFAIK. So if your makefile doesn't have something like a .mak extension then you will have to manually set it every time.

It has no extension. The setting is manual, from the Edit menu, and you can apply anything you want to a file with an 'unrecognised' extension. If the extension is unrecognised, it would be beneficial for c::b to remember any highlighting information for that file in the cbp

Highlighting Mode and File Encoding perhaps are better in the .layout, not the .cbp. Altrough it's debatable which one is better, either is better than nothing.

But to save from clutter .cbp/.layout's I'd say save this info, only when it's overriden.