The 06 October 2019 build (11872) is out.

[Frank_CB]

@oBfusCATed, @BlueHazzard

Thanks for your responses. I apparently lost the reference to 'zip' on my system. I'll fix it!

[oBFusCATed]

@nanyu: Already fixed in trunk; A workaround is to have an open project.

@raynebc: My guess is that 16 bit colour is causing it. Is there any wx3.x build of C::B which works correctly? BTW now you're one step closer to building a debug version of CB and placing a breakpoint

[raynebc]

As per the previous troubleshooting (http://forums.codeblocks.org/index.php/topic,23158.msg157800.html#msg157800), it was determined wx3.1 was what introduced the failed assertions in my scenario.  I tried connecting with the RDP client set to 32 bit color mode and this C::B nightly launched without error.  I connected with 24 bit and 15 bit color modes and launching the nightly resulted in the failed assertion messages for each.  So that does seem to be a trigger for this problem, although unless I'm misremembering, 16 bit color is the default setting for Windows' RDP for quite a while (probably at least Windows XP).

I can try to build the source code, but I don't want to install an SVN client (since I was mostly coerced to switching to Git after Google Code shut down and I transferred over to Github).  Getting the source code snapshot is taking ages though.  Are there any other unlisted build requirements other than what's listed on the Wiki article (wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Windows)?

Edit:  The source downloaded.  Do I just continue from here by opening the C::B project and trying to build it from within the IDE?

Edit 2:  I set it up as per the article as far as I can tell, but the build failed at:
#error "You need to have Direct2D capable wxWidget build to build Code::Blocks. We want to support fonts with ligatures!!!"
This compiler directive is in src\sdk\wxscintilla\src\PlatWX.cpp

Edit 3:  Trying the steps listed here (taking sodev's correction into account that include\wx\msw\setup.h is the correct file to edit):
http://forums.codeblocks.org/index.php/topic,23291.msg158631.html#msg158631

Edit 4:  Even after all that and rebuilding both wxWidgets and C::B, it failed on the same line.   I don't want to just hackishly bypass this check just to get it to compile if that will break something.  I'll wait for further guidance.

[oBFusCATed]

Just bypass the check, it is not important for what you're testing.

To fix it properly you have to find the setup.h file which is incorrect and do a rebuild.
There are multiple such files and they are copied by the wxwidgets build.

p.s. you need to have zip in path.

[Max]

Dear CB team,

I recently updated my CB nightly and I had an issue (possible bug).

Windows 7 64 bit latest SP MINGW64 GCC 8.3.0

Just after opening CB (without loading any source file or projects) I was adding an item in the help menu.....

Setting->Environment->Help Files....then any actions (click OK or cancel or try to add an item) is causing a crash (I've got an RPT, attached to this message)

Repeating the same actions with a loaded projects the crash disappears....

Hope this helps.

Max

[sodev]

Edit 4:  Even after all that and rebuilding both wxWidgets and C::B, it failed on the same line.   I don't want to just hackishly bypass this check just to get it to compile if that will break something.  I'll wait for further guidance.

After changing such elemental things its a good idea to clean up the wxWidgets source tree and remove everything from previous builds. These are the library folders that start with gcc in the lib folder and the object files folders that start with gcc in the build\msw folder.

Same applies to CodeBlocks, there it is the .obj* and devel* folders under src i think.

[BlueHazzard]

Just after opening CB (without loading any source file or projects) I was adding an item in the help menu.....

Setting->Environment->Help Files....then any actions (click OK or cancel or try to add an item) is causing a crash (I've got an RPT, attached to this message)

Repeating the same actions with a loaded projects the crash disappears....

Thank you for the report. This is already fixed in trunk and will be fixed in the next nightly build

[raynebc]

I had edited the setup.h file sodev indicated in the linked thread, and did a full clean and full rebuild of wxwidgets.  Is the makefile's "clean" target broken/insufficient for this purpose?  If I can just comment out that #error check I may just go ahead and do that.  zip.exe is already in my path.

Edit:  Commenting out that check was not enough.  The build failed with a variety of errors:

Code

sdk\wxpropgrid\include\wx\propgrid\propdev.h|18|error: aggregate 'WXDLLIMPEXP_PG_FWD wxArrayEditorDialog' has incomplete type and cannot be defined|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|32|error: variable 'WXDLLIMPEXP_PG wxPGGlobalVarsClass' has initializer but incomplete type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected primary-expression before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected '}' before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected ',' or ';' before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|37|error: expected constructor, destructor, or type conversion before ';' token|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|61|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|62|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|63|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|64|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|65|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|66|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|67|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|68|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|70|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|100|error: non-member function 'int HasExtraStyle(int)' cannot have cv-qualifier|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|105|error: expected declaration before '}' token|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|18|error: aggregate 'WXDLLIMPEXP_PG_FWD wxArrayEditorDialog' has incomplete type and cannot be defined|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|32|error: variable 'WXDLLIMPEXP_PG wxPGGlobalVarsClass' has initializer but incomplete type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected primary-expression before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected '}' before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|34|error: expected ',' or ';' before 'public'|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|37|error: expected constructor, destructor, or type conversion before ';' token|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|61|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|62|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|63|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|64|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|65|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|66|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|67|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|68|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|70|error: 'wxPGVariantDataClassInfo' does not name a type|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|100|error: non-member function 'int HasExtraStyle(int)' cannot have cv-qualifier|
sdk\wxpropgrid\include\wx\propgrid\propdev.h|105|error: expected declaration before '}' token|

[oBFusCATed]

Are you using the correct project? Suffix wx31 for wxwidgets 3.1.x, wx30 for wxwidgets 3.0.x no suffix for wx2.8 and there are 64 bit variants of wx30 and wx31 also.

[raynebc]

I hadn't noticed there were several C::B projects, I just opened the normal CodeBlocks.cbp project as directed by the wiki article (http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Windows).  Perhaps the article should be updated to reflect that the project file suited for the version of wxwidgets in question must be opened.  I picked the "CodeBlocks_wx31" project since I'm using normal MinGW (no 64 but support).  Unfortunately, cc1plus.exe keeps crashing at this point in the build:

Code

-------------- Build: sdk in Code::Blocks wx3.1.x (compiler: GNU GCC Compiler)---------------

Running target pre-build steps
.objs31\autorevision +wx +int +t .. include/autorevision.h
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -std=gnu++11 -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -Wall -g -iquote.objs31\include -I.objs31\include -I. -IC:\wxwidgets\include -IC:\wxwidgets\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c C:\cb_svn\src\sdk\configmanager-revision.cpp -o .objs31\sdk\configmanager-revision.o
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -std=gnu++11 -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -Wall -g -iquote.objs31\include -I.objs31\include -I. -IC:\wxwidgets\include -IC:\wxwidgets\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c C:\cb_svn\src\sdk\annoyingdialog.cpp -o .objs31\sdk\annoyingdialog.o

[oBFusCATed]

With this nightly, predefined breakpoints no longer seem to trigger.

By prefdefined I mean ones that I previous set in the Project/targets options->Debugger->Additional GDB Commands dialog as 'break FuncName'. They are still shown but now seem to have no effect.

Going back to the previous nightly fixes this issue.

Fix in trunk rev11876, thanks for reporting and sorry for breaking it.

[oBFusCATed]

@raynebc: Currently I'm using mingw-w64 to build codeblocks and I don't have problems with, but I'm building the 64bit version of wx3.1.

[raynebc]

I don't know if I want to change toolsets just to try to get C::B to build, I don't want to do anything that will break my MinGW installation.  If a debug build can add some logging or dialog messages to identify where the assertions are failing, I'll try it.

[AndyJ]

With this nightly, predefined breakpoints no longer seem to trigger.

By prefdefined I mean ones that I previous set in the Project/targets options->Debugger->Additional GDB Commands dialog as 'break FuncName'. They are still shown but now seem to have no effect.

Going back to the previous nightly fixes this issue.

Fix in trunk rev11876, thanks for reporting and sorry for breaking it.

Thank you for addressing this so quickly. Looking at your change explains why my colleague wasn't  seeing this when remote debugging. I look forward to the next nightly!

[Max]

Dear CB Team,

Another (very minor) issue I had, updating from an older (11781) nightly build, is the disappearing of the spell-checker flags from the main CB window. The string en_GB is now displayed instead of showing the UK flags.

Spell-checker works as usual but the flags is no longer present. Using the previous 11781 the flags  were displayed correctly.

Is a very minor issue and CB is perfectly usable but I'm wondering if it is a CB issue or a problem due to my configuration.

Windows 7 latest SP MinGW64 GCC 8.3.0 display resolution 1280 x 1024 (the recommended resolution for my monitor)

Any comment?