The 12.11 RC1 (11 November 2012 build 8549) is out.

[SC]

Hi,
I would like to thank you for this great peace of software and for sharing it with us. I have used codeblocks from time to time in the past and more regularly in the last weeks and I think that it is probably the cross platform IDE that has the more functionalities.
I have been testing this last release and there are a few things that I find unfortunate. Although these are not really bugs but more design choices

1) Concerning the project build options, I don't really get why one should select a compiler at the project level while different compilers can be selected at the build target level. For example, when using GCC as the default compiler for the project, C::B adds the option "-fexception" to the "Compiler settings"-"Other options" tab which will pollute the other build targets for which it is not a valid option. Although one could change the Compiler policy from "append target options to project options" to "use target options only", it would probably be simpler if there was no compiler choice/option at the project level.

2) When using several build targets / environments, it happens that it is not possible to change the compiler flags for a compiler that is not installed on the computer even if the build target already exists in the project. For example if one uses MSWindows/MSVC and GnuLinux/GCC, shouln't it be possible to change MSVC compiler flags without having to log on a computer where MSVC would be present?

3) Apparently, when both MSVC2005 and MSVC2008 are installed, C::B does not make the difference and adds the the search directories of the two compilers for standard headers. When right-clicking on a given #include instruction for a STL header and click on "Open #include file", one is not sure of which header is openned/included.

Thank you again for your work

SC.

[stahta01]

Windows RC1 debug plugin design question.

After removing the debug plugin on Windows 7, the "view" -> "toolbars" still shows the debugger menu option.
Should it?
Note: The menu option is selected then displays the debugger menu.

I considered it not really worth the effort to fix; but, if it was not on purpose and the fix is easier it might be worth fixing before the final release.

The other toolbars menu options go away if the plugin is disabled.

NOTE: Trying to uninstall the debug plugin fails (almost crashes CB)  for me unless I do it in Administrator mode on Windows 7 32 bit.

Tim S.

[MortenMacFly]

1) Concerning the project build options, I don't really get why one should select a compiler at the project level

This is definitely useful. It depends on what you are developing. If you develop using one compiler, but your targets are different editions of you software (or maybe app + plugins) you save yourself a lot of time for the setup.
On the other hand, if you develop and must be compatible to a range of compilers, each target using a different compiler is useful, too.
So this won't change as it is "by design". C::B also only adds flags automatically if you use the wizard in the first place. If you don't like that, right-click on the wizard, select edit and switch off the flag generation.

2) When using several build targets / environments, it happens that it is not possible to change the compiler flags for a compiler that is not installed on the computer

I cannot reproduce. It works just fine here. Maybe you setup the target so that it is "Windows only"? In that case, just don't do it and you can change flags as you like. (I can.)

3) Apparently, when both MSVC2005 and MSVC2008 are installed, C::B does not make the difference

Again: I cannot reproduce. I have two targets: MSVC 2005 and MSVC 2008 and if I change flags for the one target the other is not affected. What exactly are you doing? Steps to reproduce, please?

Maybe you should start and read the manual first...?!

[and4cb]

Hello oBFusCATed:  Based on your reply, I have edited my post to make it more readable, and I am using the Task Manager to "kill" gdb when necessary.

Can you reproduce this problem on a simple example project?

Here is a simple program that demonstrates the problem.
(If I should be posting this question in a different thread, please let me know.)
I am grateful for any clue you can give me to solve this problem.

Code

#include <stdio.h>
#include <stdlib.h>

int INUM1 = 0;

int main(void);  //prototype
void Initialize(void);  //prototype
int InitNum(int num);  //prototype

int main(void)       // "Run to cursor" here, then "Next line"
{
    Initialize();    // "Step into"

    return 0;
}

void Initialize(void)
{
    printf("\nBefore call to InitNum(), INUM1 = %d", INUM1);

    //When I Step Into this next line
    // the Debug buttons become disabled
    // and to "kill" gdb, I must use Task Manager
    INUM1 = InitNum(4);

    printf("\nAfter call to InitNum(), INUM1 = %d", INUM1);
}

int InitNum(int num)
{
    num = (num + 4);
    return num;
}

Debugger Log:

Code

Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: C:\Code\test5\
Adding source dir: C:\Code\test5\
Adding file: C:\Code\test5\bin\Debug\test5.exe
Changing directory to: C:/Code/test5/.
Set variable: PATH=.;C:\MinGW32\bin;C:\MinGW32;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared;C:\Program Files (x86)\Common Files\DivX Shared;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn;c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn;C:\Program Files (x86)\QuickTime\QTSystem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Windows Live\Shared

[debug]Command-line: C:\MinGW32\bin\gdb.exe -nx -fullname  -quiet  -args C:/Code/test5/bin/Debug/test5.exe
[debug]Working dir : C:\Code\test5

Starting debugger: C:\MinGW32\bin\gdb.exe -nx -fullname  -quiet  -args C:/Code/test5/bin/Debug/test5.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from C:\Code\test5\bin\Debug\test5.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.5
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-pc-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.5

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> source C:\cb20121112\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Code/test5/
[debug]Source directories searched: C:/Code/test5;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> tbreak "C:/Code/test5/main.c:10"
[debug]Temporary breakpoint 1 at 0x40133f: file C:\Code\test5\main.c, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: C:\Code\test5\bin\Debug\test5.exe 

Child process PID: 2540

[debug][New Thread 2540.0x1450]
[debug]Temporary breakpoint 1, main () at C:\Code\test5\main.c:12
[debug]C:\Code\test5\main.c:12:233:beg:0x40133f
[debug]>>>>>>cb_gdb:

At C:\Code\test5\main.c:12

[debug]> bt 30
[debug]#0  main () at C:\Code\test5\main.c:12
[debug]>>>>>>cb_gdb:
[debug]> step
[debug]Initialize () at C:\Code\test5\main.c:19
[debug]C:\Code\test5\main.c:19:312:beg:0x401351
[debug]>>>>>>cb_gdb:

At C:\Code\test5\main.c:19

[debug]> bt 30
[debug]#0  Initialize () at C:\Code\test5\main.c:19
[debug]#1  0x00401344 in main () at C:\Code\test5\main.c:12
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]C:\Code\test5\main.c:24:508:beg:0x401366
[debug]>>>>>>cb_gdb:

At C:\Code\test5\main.c:24

[debug]> bt 30
[debug]#0  Initialize () at C:\Code\test5\main.c:24
[debug]#1  0x00401344 in main () at C:\Code\test5\main.c:12
[debug]>>>>>>cb_gdb:
[debug]> step
[debug]InitNum (num=4) at C:\Code\test5\main.c:31
[debug]>>>>>>cb_gdb:

Trying to pause the running process...

[gersen]

Hi,
first of all thank you for this great tool, I'm using it a lot lately for "exotic" targets like native client or flascc and even emscripten. It is very useful when your compiler is quite standard but don't provide an ide.

Since we are approaching a new stable release I would like to report a bug that is present on this RC1 and basically on all the nightly I've used so far. It is not a big thing but it is quite annoying. On my code I use a lot of

#ifdef PLATFORM_A
//code
#elif PLATFORM_B
//code
#elif PLATFORM_C
//code
#endif

Those PLATFORM_X defines are set in the various project build options. I have also enabled the option "Interpret #if, #else, #endif to gray out inactive preprocessor-code" and its two sub-options under Setting->Editor->C/C++ Editor Settings. All works well but if I leave some open files with those #ifdef and close and reopen CB, open that project all the previous open files (I use the option "open last open files") have wrong gray out inactive preprocessor. If I close those files and reopen them they are correctly gray out. It seems that the files automatically open when you open a project are not being preprocessed by the ide (or something like that).

Thank you and keep up the good work,
 Thomas

[SC]

1) Concerning the project build options, I don't really get why one should select a compiler at the project level

This is definitely useful. It depends on what you are developing. If you develop using one compiler, but your targets are different editions of you software (or maybe app + plugins) you save yourself a lot of time for the setup.
On the other hand, if you develop and must be compatible to a range of compilers, each target using a different compiler is useful, too.
So this won't change as it is "by design". C::B also only adds flags automatically if you use the wizard in the first place. If you don't like that, right-click on the wizard, select edit and switch off the flag generation.

I understand your point. Thanks for your answer.

2) When using several build targets / environments, it happens that it is not possible to change the compiler flags for a compiler that is not installed on the computer

I cannot reproduce. It works just fine here. Maybe you setup the target so that it is "Windows only"? In that case, just don't do it and you can change flags as you like. (I can.)

Well, if I try to change compiler flags for MSVC8 under linux, I get "the defined compiler cannot be located (ID:msvc8)" even though the build target is not set up to "Windows only".

3) Apparently, when both MSVC2005 and MSVC2008 are installed, C::B does not make the difference

Again: I cannot reproduce. I have two targets: MSVC 2005 and MSVC 2008 and if I change flags for the one target the other is not affected. What exactly are you doing? Steps to reproduce, please?

I will send you a more detailed description of the problem separately.

Maybe you should start and read the manual first...?!

That is for sure. But when you give a gameboy to a kid, he starts playing with it before reading the manual (and it is probably the most efficient way to understand how to use it!). I really like codeblocks and find it very intuitive. Although I did have a look into the documentation before describing these issues. Once again, thank you for sharing this great piece of software. I will send a more detailed description of the third point.

[Alpha]

It seems that the files automatically open when you open a project are not being preprocessed by the ide (or something like that).

Known problem , unfortunately, unknown solution .

2) When using several build targets / environments, it happens that it is not possible to change the compiler flags for a compiler that is not installed on the computer

I cannot reproduce. It works just fine here. Maybe you setup the target so that it is "Windows only"? In that case, just don't do it and you can change flags as you like. (I can.)

Well, if I try to change compiler flags for MSVC8 under linux, I get "the defined compiler cannot be located (ID:msvc8)" even though the build target is not set up to "Windows only".

This is because the Windows-only compilers "do not exist" in Linux builds.  The XML Compiler branch has changed this behavior, but this branch will not be merged until after the release.

[stahta01]

Patch for NON-PCH building under Windows 7.
Needed to remove warning and error on Windows 7 build done with NOPCH and without CB_PRECOMP and WX_PRECOMP.

Including sdk_precomp.h is valid for the SDK not valid for Plug-ins and Main executable under Windows.

Strange Error: when not including wx/button.h.

Code

..\..\..\.objs\plugins\contrib\help_plugin\MANFrame.o:MANFrame.cpp:(.rdata$_ZTV18wxBitmapButtonBase[__ZTV18wxBitmapButtonBase]+0x2dc)||undefined reference to `wxButton::GetClassInfoW() const'|

Code

Index: src/plugins/contrib/help_plugin/MANFrame.cpp
===================================================================
--- src/plugins/contrib/help_plugin/MANFrame.cpp	(revision 8574)
+++ src/plugins/contrib/help_plugin/MANFrame.cpp	(working copy)
@@ -10,6 +10,7 @@
 
 #ifndef CB_PRECOMP
   #include <wx/arrstr.h>
+  #include <wx/button.h>
   #include <wx/dir.h>
   #include <wx/filename.h>
   #include <wx/sizer.h>
Index: src/src/breakpointsdlg.cpp
===================================================================
--- src/src/breakpointsdlg.cpp	(revision 8574)
+++ src/src/breakpointsdlg.cpp	(working copy)
@@ -7,7 +7,7 @@
  * $HeadURL$
  */
 
-#include "sdk_precomp.h"
+#include "sdk.h"
 
 #ifndef CB_PRECOMP
 #   include <algorithm>

Tim S.

[oBFusCATed]

In svn...

[raynebc]

I was running splint on a program I work on and fixing casual warnings like ignoring return values from functions.  I found that casting the return value as void, ie:

Code

(void) functioncall():

Breaks Code::Blocks's ability to find functioncall's declaration or implementation, such as from the context menu.  If I delete the void typecast and try to have C::B find the function's declaration, it brings up a list of two declarations to choose from:

Code

int functioncall(void)
(void) callingfunctionname::function

Showing that the void cast confused C::B's parser.  Re-parsing the project doesn't correct or avoid this bug.  I just figured I'd mention it because the find declaration/implementation was screwy in the last nightly I tried as well (10-13-12  nightly), where sometimes it would fail to find the declaration/implementation, then when I tried it again a second later, it would find it.

Edit:  Also, I noticed another bug where when I do a search and replace within all of the project's files, when it completes the operation, it does not render the source file is selected.  It made me think C::B had hung until I noticed that all of the rest of the GUI was responsive.

[and4cb]

oBFusCATed:  Since my problem does not seem to be related to this Nightly update, since the 10/23 update has the same problem for me, I have opened a new topic in the Help forum titled, "Debugger sometimes stalls when using 'Step Into'."

[MortenMacFly]

Edit:  Also, I noticed another bug where when I do a search and replace within all of the project's files, when it completes the operation, it does not render the source file is selected.  It made me think C::B had hung until I noticed that all of the rest of the GUI was responsive.

If you compile C::B yourself, can you try the following patch:

Code

Index: src/sdk/editormanager.cpp
===================================================================
--- src/sdk/editormanager.cpp	(revision 8584)
+++ src/sdk/editormanager.cpp	(working copy)
@@ -2219,9 +2219,12 @@
 
     // if we showed the progress, the app window is frozen; unfreeze it
     if (progress)
+    {
+        delete progress;
         Manager::Get()->GetAppWindow()->Thaw();
+    }
 
-    delete progress;
+    Manager::Get()->GetAppWindow()->Refresh();
     return pos;
 }
 

?

[dmoore]

If you compile C::B yourself, can you try the following patch:

I can't actually replicate the issue... What is the problem that this is solving? (and how do I reproduce?)

[MortenMacFly]

I can't actually replicate the issue... What is the problem that this is solving? (and how do I reproduce?)

- have a project with many files (with dummy content)
- run a "Replace in files" operation
- make sure things get replaces and e.g. editors are open whose content is updated
-> after the operation has finished (and editors were opened) C::B seems like "dead", an UI refresh seems missing.

[raynebc]

Thanks!  I'm glad to hear that one was sorted out quickly.  However now since I've casted all unused return values to (void), I will no longer be able to use the find declaration/implementation features, which will make thinks a little less convenient.  Here's to hoping it's also a simple fix.