The 03 June 2012 build (8024) is out.

[MortenMacFly]

- Reportedly there is now an option to set a new maximum for Aligner entries, but I cannot find it anywhere. I still get 4 entries and the rest are cropped (same as before).

See settings -> Editor -> Editor Tweaks Settings

[carra]

Oh man, I was looking for a submenu and you guys made a whole new settings tab for it! Found it, and it works as intended. Thanks!

[MortenMacFly]

Oh man, I was looking for a submenu and you guys made a whole new settings tab for it!

Yes, because as EditorTweaks has many functions, there may be more options more to come...

[xunxun]

Found a CC plugin bug.

When loading a new project, CC plugin will decode the variable's declaration and show one time, but if you want to show again, it will show many times.

The demo project is in the attachment.

[oBFusCATed]

I've seen this, too, but I was not sure how to reproduce it.

[MortenMacFly]

I've seen this, too, but I was not sure how to reproduce it.

I have a patch for this already in my local copy... just didn't commit so far. Don't worry about this.

[oBFusCATed]

Then go on and commit it 

[ollydbg]

Good, I review the commit, I see this is the quite good fix:

Code

@@ -1807,7 +1815,7 @@ size_t NativeParser::MarkItemsByAI(ccSearchData* searchData, TokenIdxSet& result
 
     CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokensTreeMutex)
 
-    RemoveLastFunctionChildren(tree, m_LastFuncTokenIdx);
+    RemoveLastFunctionChildren(m_Parser->GetTokensTree(), m_LastFuncTokenIdx);
 
     // find "using namespace" directives in the file
     TokenIdxSet search_scope;

The old way "tree" is a temporary Tokenstree, and already cleared before. What we need to clean is the normal Tokenstree.

[MortenMacFly]

The old way "tree" is a temporary Tokenstree, and already cleared before. What we need to clean is the normal Tokenstree.

Yes, I think this was my fault in the end...

[xunxun]

I've seen this, too, but I was not sure how to reproduce it.

I have a patch for this already in my local copy... just didn't commit so far. Don't worry about this.

Thanks @MortenMacFly.
 

[carra]

Hi again, I have had some unexpected behavior with relative directories under C::B and I wonder if I should consider this a bug in C::B project system??

* Project base folder: C:\Programacion\KTools\Sources\LogStream
* Output folder for objects:  ..\..\Objects  (i.e.: "C:\Programacion\KTools\Objects")
* 3 Files in project:
    - ..\..\Headers\General.hpp       (i.e.: "C:\Programacion\KTools\Headers\General.hpp")
    - ..\..\Headers\LogStream.hpp   (i.e.: "C:\Programacion\KTools\Headers\LogStream.hpp")
    - LogStream.cpp                     (i.e.: "C:\Programacion\KTools\Sources\LogStream\LogStream.cpp")

No matter what I try, instead of the intended Objects directory, my objwect files end up in the following directory:

"C:\Programacion\KTools\Objects\Sources\LogStream"

Seeing the resulting command line, it seems as if C::B is doing the following folder concatenation for some reason:

(1) In the Project Explorer, the source file appears listed as "Sources\LogStream\LogStream.cpp" (why all that route? it's in the project's base directory!!)

(2) What seems to be happening is:
"C:\Programacion\KTools\Objects" + "Sources\LogStream\LogStream.cpp" ==> "C:\Programacion\KTools\Objects\Sources\LogStream\LogStream.o"

[carra]

OK, since the project file is very simple I thought I might post it here.
For simplicity, I have parameterized folders with an env var KTOOLS_FOLDER which in my case is: C:\Programacion\KTools

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Option title="LogStream" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Release">
				<Option output="$(KTOOLS_FOLDER)\Libraries\LogStream" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="$(KTOOLS_FOLDER)\Objects" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Option createDefFile="1" />
				<Compiler>
					<Add option="-Wall" />
					<Add option="-O2" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<Unit filename="..\..\Headers\General.hpp" />
		<Unit filename="..\..\Headers\LogStream.hpp" />
		<Unit filename="LogStream.cpp" />
		<Extensions>
			<code_completion />
			<envvars />
			<debugger />
			<lib_finder disable_auto="1" />
		</Extensions>
	</Project>
</CodeBlocks_project_file>

If I had to guess, I'd say that C::B is trying to set a "common base folder" for all the project files. As if it didn't properly support routes with "\.." in them.

[saidus]

Hello.
Is there any ready to download package for windows (codeblocks-setup-10.05.8024.exe) with the current svn release.
Thank you .

[gd_on]

may-be that one : http://forums.codeblocks.org/index.php/topic,13234.msg88948.html#msg88948

gd_on

[carra]

It's curious... the problem I reported earlier with relative paths seems not to be present in nightly 7925. The very same project I posted produces the object in the correct folder. A regression?