User forums > Nightly builds

The 01 october 2006 build is out.

(1/4) > >>

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.


--- End code ---

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.

--- End code ---

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 :P

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:

--- Quote from: BigAngryDog on October 02, 2006, 04:32:38 am ---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. :)

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page