The 19 September 2010 build (6608) is out.

[MortenMacFly]

- I have the same problem with folding.

Can you try the attached patch, please (other interested please as well).

[Jenna]

- I have the same problem with folding.

Can you try the attached patch, please (other interested please as well).

Does not change anything.
Nevertheless the solution is quite simple, we just have to move all the folding stuff from InternalSetEditorStyleBeforeFileOpen to InternalSetEditorStyleAfterFileOpen.
I will commit the fix later.

[Jenna]

I just committed a fix for the folding stuff, and also a patch to make it optional to grey(better black)-out inactive preprocessor-code.
A fix for the broken wxSmith colour-property is also committed, other broken wxSmith stuff (due to update of wxPropgrid) will (hopefuly) follow.

[ultimA]

Here is a bug report for console projects. This happens on a 32bit Windows 7 computer. It happens in the debugger branch too and it existed in previous revisions (bug is not new to 6608). A sample project with source is attached.

1) Throw an exception in c++ while running the code in CodeBlocks (not while debugging). Let it be unhandled.
2) Windows will report that the application has crashed and will offer to close the application or search for a solution. Choose to close now.
3) The console will now prompt to "Press any key to continue". Do not press a key.
4) Click 'Abort' in CodeBlocks.
5) Now the process will stay stuck in CodeBlocks. Even though the application has closed, the debugging does not stop. If you click on 'Abort' in CodeBlocks, nothing happens. You also cannot debug/continue anymore since the debugger is already running, but you cannot stop it. Only solution is to kill cb_console_runner.exe in task manager or restart CodeBlocks.

Here is another list of events that trigger the same bug:
1) Throw an exception in c++. Let it be unhandled.
2) Windows will report that the application has crashed. Do nothing here.
3) Click 'Abort' in CodeBlocks.
4) Back to the Windows dialog. Choose to close the program.
5) cb_console_runner.exe is stuck again.

Here is an order of events that does work well:
1) Throw an exception in c++. Let it be unhandled.
2) Windows will report that the application has crashed. Choose to close now.
3) The console will now prompt to "Press any key to continue". Press a key.
4) Everything works fine as expected.


[attachment deleted by admin]

[MortenMacFly]

Does not change anything.

Nah... my bad. It was a "blind shot" after quickly scanning the scintilla docu. :-(

Time to get back to a PC where I can compile C::B... 3 days left...

[adfm]

+1 for the #ifdef blocks being grayed out even if the #define exists

[daniloz]

+1 for the #ifdef blocks being grayed out even if the #define exists

-1, i.e. I'd prefer the active #ifdef block, based on the #define and project defines, to be normally colored; and the inactive ones to be grayed out...

[MortenMacFly]

+1 for the #ifdef blocks being grayed out even if the #define exists

-1, i.e. I'd prefer the active #ifdef block, based on the #define and project defines, to be normally colored; and the inactive ones to be grayed out...

You both have the option to do as you like with the next nightly thanks Jens.

[eckard_klotz]

Hello Developer-Team.

Since today I'm able to submit a bug-report again. I used this, to report my "not able to find the location associated to the cppcheck-message by click"-problem under the bug-id 017522 and the summary "CppCeck not able to find location associated to message".

Don't take me wrong. I know, I have to be patient and please believe me I am. I only wonder if my try to load up the example-project under "http://forums.next.codeblocks.org/index.php/topic,13243.15.html" was successful, since you asked for an example.

A little "We've got it and it shows the described effect " will be nice, even if a "but currently we have to work on something else" follows.

Regards,
              Eckard.

[ultimA]

A crash report. It happened while opening the Code Profiler plugin using a custom makefile. SVN 6620.

[Jenna]

A crash report. It happened while opening the Code Profiler plugin using a custom makefile. SVN 6620.

Works here, can you create a sa(i)mple project where this error occurs and attach it here (zipped) ?

[vertacomi]

Hello the code::blocks team,

I try to put in the "Default code" section in the editor configuration some comment with svn keywords like

/**
* \file
* \brief
* $HeadURL$
* $Author$
* $Date: 2010-09-24$
* $Rev$
*/

And when I Select File > New > File ...

The svn keyword are partially removed like that :
/**
* \file
* \brief
* $
* $
* : 2010-09-24$
* $
*/


Thanks for your works.

[Jenna]

Hello the code::blocks team,

I try to put in the "Default code" section in the editor configuration some comment with svn keywords like

/**
* \file
* \brief
* $HeadURL$
* $Author$
* $Date: 2010-09-24$
* $Rev$
*/

And when I Select File > New > File ...

The svn keyword are partially removed like that :
/**
* \file
* \brief
* $
* $
* : 2010-09-24$
* $
*/


Thanks for your works.

If you double the first dollar-sign it should work, otherwise it interferes with C::B's macro-replacement.

Code Select Expand

/**
* \file
* \brief
* $$HeadURL$
* $$Author$
* $$Date: 2010-09-24$
* $$Rev$
*/

[vertacomi]

Thanks Jens !

[ultimA]

A crash report. It happened while opening the Code Profiler plugin using a custom makefile. SVN 6620.

Works here, can you create a sa(i)mple project where this error occurs and attach it here (zipped) ?

Here is a minimalistic project. Compile, run, then try to use the Code Profiler plugin. Crashes reliably on my Arch Linux system. I think it has something to do with the compiler flags used.

And sorry to ask, but any news on cb_console_runner.exe getting stuck? This crash is kind of unlikely, because it only happens in some cases using custom makefiles. But that cb_console_runner.exe getting stuck is really annoying. And it happens on Linux too, although there is no cb_console_runner.exe in that case.