The 12 October 2014 build (9958) is out.

[Alpha]

click somewhere in your editor => move the mouse ==> the entire content gets selected (better don't press another key) ...

Hmm... now I am experiencing this, except it only occurs when the mouse hovers on a spot (calls tool tip).  Executed clean, then build from within C::B (Ubuntu).

[Jenna]

I still don't get this on the C::B 9959 from my repo.
Can you check the dependencies with "ldd" ?
Do you have older C::B revisions on your system that might interfere ?

[eckard_klotz]

Hello Everybody.

Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. « Reply #31 on: June 20, 2013, 03:15:01 pm » please scroll up since the link does not show the first post) . Since we decided to move some parts of the discussion you will find some parts at http://forums.codeblocks.org/index.php/topic,18081.msg125445.html#msg125445 ( Moritz plugin « on: June 21, 2013, 08:20:45 am »)

The effect is that namespaces nested in other namespaces will be shown parallel to their parent namespaces in the symbol-browser. Furthermore if you click on them in them, just the defining headerfile will be opened but without showing the line where the namspace will beopened. To reproduce this effect please download The files:

• src_Moritz2_2014_01_25.zip at http://sourceforge.net/projects/moritz/files/Moritz_2.x/Moritz_2_0_0/
  
• src_MuLanPa_2014_01_25.zip at http://sourceforge.net/projects/mulanpa/files/MuLanPa_1/MuLanPa_1_0_0/
  

This archives contain a C::B project and the sources for the associated binary. Please open the projects with the last 3 nightlies

• September the 16th 2014 -> nested namespaces are shown only as child of their parents
• October the 11th 2014-> nested namespaces are shown as child of their parents as well as independend namspace
• October the 12th 2041-> nested namespaces are shown as child of their parents as well as independend namspace

Since their is still no posibility to add virtual folders in the symbol browser like you can do in the project browser I use namespaces to have a more structed view. Without this the symbol browser is not realy helpfull for greater projects. Thus I hope that the effect I described above is only a bug and no feature.

The environment where I observed this effect is a sony-laptop (VAIO) with Windows 8.1. First tests on WinXP didn't show this effect But I did this check with an other project. Furthermore I try to do the same with Windows 7.

Best regards,
                   Eckard Klotz.

[teto]

@Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..

I think it is. Cool ! I am eager to try the next nightly.

[Jenna]

@Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..

I think it is. Cool ! I am eager to try the next nightly.

A new build of my debian packages should be available this afternoon.
I try to build and upload the Fedora/CenTOS packages als, but I can not do this on my server (runs under debian), so I have to upload more than 500 MB and I don't know if I find the time to do so, because I will most likely not have (fast) internet access from tomorrow on for the next ten to ? days (I will be in hospital with my daughter).
And compiling all packages takes some hours.

[ollydbg]

Hello Everybody.

Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. « Reply #31 on: June 20, 2013, 03:15:01 pm » please scroll up since the link does not show the first post) . Since we decided to move some parts of the discussion you will find some parts at http://forums.codeblocks.org/index.php/topic,18081.msg125445.html#msg125445 ( Moritz plugin « on: June 21, 2013, 08:20:45 am »)

The effect is that namespaces nested in other namespaces will be shown parallel to their parent namespaces in the symbol-browser. Furthermore if you click on them in them, just the defining headerfile will be opened but without showing the line where the namspace will beopened. To reproduce this effect please download The files:

• src_Moritz2_2014_01_25.zip at http://sourceforge.net/projects/moritz/files/Moritz_2.x/Moritz_2_0_0/
  
• src_MuLanPa_2014_01_25.zip at http://sourceforge.net/projects/mulanpa/files/MuLanPa_1/MuLanPa_1_0_0/
  

This archives contain a C::B project and the sources for the associated binary. Please open the projects with the last 3 nightlies

• September the 16th 2014 -> nested namespaces are shown only as child of their parents
• October the 11th 2014-> nested namespaces are shown as child of their parents as well as independend namspace
• October the 12th 2041-> nested namespaces are shown as child of their parents as well as independend namspace

Since their is still no posibility to add virtual folders in the symbol browser like you can do in the project browser I use namespaces to have a more structed view. Without this the symbol browser is not realy helpfull for greater projects. Thus I hope that the effect I described above is only a bug and no feature.

The environment where I observed this effect is a sony-laptop (VAIO) with Windows 8.1. First tests on WinXP didn't show this effect But I did this check with an other project. Furthermore I try to do the same with Windows 7.

Best regards,
                   Eckard Klotz.

If I remember correctly, we have some patches from Huki which handle "unnamed namespaces", which may cause this issue, maybe other patches of CC. Any way, I will look into it.

[eckard_klotz]

Hello Ollydbg.

Thanks for your reply. I hope you are able to reproduce the effect while using my source-archives. In the meanwhile I also tested it on Win XP and Win 7 and I've got the same result as described for Win 8.1.

Best regards,
                   Eckard.

[Jenna]

@Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..

I think it is. Cool ! I am eager to try the next nightly.

svn r9990 for debian and r9989 for Fedora/CentOS are available on my server.

[Alpha]

Do you have older C::B revisions on your system that might interfere ?

Some.. but they all should be isolated.

I did a "scorched earth" rebuild by manually purging everything that does not come from a fresh checkout.  Seems to be working so far.

[teto]

svn r9990 for debian and r9989 for Fedora/CentOS are available on my server.

Works perfectly now. Thanks. I hope everything will be fine for you during the coming days.

[ollydbg]

Hello Everybody.

Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. « Reply #31 on: June 20, 2013, 03:15:01 pm » please scroll up since the link does not show the first post) .
...
...

I looked at the post: Re: The 16 June 2013 build (9158) is out.
I have debugged a little, but I think it is the expect behavior.
If we have this sample code:

Code

namespace a {
namespace b {
};
};

using namespace b;

There are two tokens named "b" in the TokenTree.
One is the sub namespace under a. (the first b)
One is in global namespace. (the second b)

[MortenMacFly]

There are two tokens named "b" in the TokenTree.
One is the sub namespace under a. (the first b)
One is in global namespace. (the second b)

Looks OK to me. Maybe the guy is missing to use:
using namespace a::b?

[teto]

When replacing a string across files, the final box displays:
"Replace in files has finished all operations."
Iirc, codeblocks used to display the number of changes like "string replaced 8 times across 7 files". I wonder if that could be brought back. Sometimes when replacing strings, I forget to untick some boxes (ie, "Match case"), thus replacing more strings than I intended to. The display of the number of replacements used to help me realizing these errors.

[eckard_klotz]

Hello Ollydbg and Morten

Thanks for your evaluation of my report.

There are two tokens named "b" in the TokenTree.
One is the sub namespace under a. (the first b)
One is in global namespace. (the second b)

Looks OK to me. Maybe the guy is missing to use:
using namespace a::b?

It seems that you used my simple example from one year ago and did not downloaded the real projects. As far as I remember there was a little problem in this first example but I'm not sure anymore what it was. Thus please check my source projects provided as link also.

In the case that my simple example was programmed in the same way as in my real projects, it seems taht it is good enough to explain my problem. In the past until the nightly fom September the 16th 2014 b was shown only one times only as  sub namespace under a. And exactly this was for me the reason why I implemented this namespaces. If you have a greater project with many classes and/or many classless functions (as in a c-project), the list shown in the symbol-browser is real huge and less helpfull to find a special source-element.
Even child-classes are shown in root-list. Until September the last posibility to define for the symbol browser an usedefined tree structure was to use namespaces, since the definition of virtual folders like in the project browser are not available.

How ever please check my problem by using my source-project and if you than schow me a mistake in my code as the real reason of my problem, than I will change it. But as you can see by my old posts as reaction you changed somewhat in Code::Blocks and the namespaces were shown again as in the older nightlies.

You may now argue (for what reasons ever), that you don't want to change it any more, since this is exactly the behaviour you want. In this case it would interst me, what you have planned or already implemented to enable an reduction of viewd lists in the symbol browser for great projects. 

Thanks and best regards,
                                    Eckard.

[ollydbg]

It seems that you used my simple example from one year ago and did not downloaded the real projects.

Yes, but I'm checking your zip files now.

In the case that my simple example was programmed in the same way as in my real projects, it seems that it is good enough to explain my problem. In the past until the nightly from September the 16th 2014 b was shown only one times only as  sub namespace under a.

In your "simple example", showing a b under root(global namespace) is correct, right?
Note that I can open your projects(cbp files), and I'm not sure what is the wrong behavior? Can you give me a screen shot of the symbol browser? Which namespace is not shown correctly? What is the expected symbol browser tree? In my testing system with the latest trunk, I don't see much issue, but sometimes, symbol browser don't show any labels, not sure this is the same issue as you complained.

BTW: I see that there are many typos in your last post, do you enable the spell check in your web browser? Firefox in my system will display a wavy line beneath spell errors.