The 01 September 2023 build (13344) is out.

[killerbot]

We switched to gcc 13.1.0 (on 04 June 2023) --> download the new wx/mingw dll's see link below

Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.5-11.0.0-ucrt-r5/winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64ucrt-11.0.0-r5.7z

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw32u_gcc_cb_wx3221_2D_gcc1310-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls13.1.0.7z


The 01 September 2023 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2023/CB_20230901_rev13344_win64.7z
  - Linux :
   none

The current SDK version is : 2.24.0

Resolved Fixed:

• Fix assertion introduced in [r12537] (thanks pirx67)
• ToDoListView - Avoid invalid date assertion when sorting date column
• Spellchecker: Fix big memory leak (ticket #1405, thanks Christo)
• Spellchecker: Fix big memory leak (ticket #1405, thanks Christo)
• clangd_client 1.2.74 23/08/28 Apply patch 1406 for pJson leak in client.cpp (Thanks Christo)
• wxSmith: Remove assertion when wxSHAPED is checked and Proportion != 0

Regressions/Confirmed/Annoying/Common bugs:

[ReleaseDate]

Hey Killerbot. Please kill the 20.03 version. It got so old. We are expecting a new release in this month. I hope you will upload it.

[cookepuss]

Agreed. Nightly builds are fine for those want the latest and don't need hand holding. However, having an official release that is now 3.5 years old makes CodeBlocks seem like abandonware. Fewer people will see it as a viable option, alternative if it appears to be forgotten by the developers. If nothing else, the team has to be concerned with the optics.

[killerbot]

we are preparing a release, but we all have busy schedules, so sometimes it does not go as quick as we would like, but this year we will sure pull it of :-)

[ReleaseDate]

Thanks. This is a quite useful, good development environment. I use it for cross-platform projects.

[cookepuss]

we are preparing a release, but we all have busy schedules, so sometimes it does not go as quick as we would like, but this year we will sure pull it of :-)

Yeah. Nobody's calling you guys lazy, fwiw.

I'm mostly thinking about the new users. Lots of books and sites recommend CodeBlocks. It's probably the best, most accessible alternative out there. That's why.

Current users already know that CodeBlocks is updated relatively frequently. New users coming from one of those sites or having read one of those books? Not so much. They'll just do a cursory examination of the downloads area and say, "Oh. Wow. This hasn't been updated in years. I don't want to invest my time using something that's dead." and move along. I'm not sure that's what anybody wants. CodeBlocks has really become an invaluable resource to the indie and student communities who really aren't fans of Microsoft's offering.

ANYWAY... Thanks for the update. Looking forward.

[fcloud2020]

Hi.
After testing, I think the problems I reported in build 13300 have not been completely solved.
wxSmith still has some problems.
When I selected the 'shaped' property of one control, it's no problem.  But compiled and running, the same problem arised again. The good news is that CodeBlocks doesn't crash.

[Miguel Gimenez]

You must set Proportion to 0 when Shaped is checked, this is a wxWidgets restriction. You can disable assertions in wxWidgets, see their docs.

[Zhaolin Lau]

The UI looks outdated hmm...

[fcloud2020]

You must set Proportion to 0 when Shaped is checked, this is a wxWidgets restriction. You can disable assertions in wxWidgets, see their docs.

Thank you for your help in your busy schedule.
When we select the "shape" property of a control, it would be helpful for users if wxSmith would give us a prompt window telling us that the "proportion" attribute must be set to "0".
After all, not everyone is as knowledgeable about wxwidgets as you are.

[Xaviou]

Hi.

OS X version of this rev can be downloaded from my Google Drive.
There is only a macOS-11.6 version.
Note that it is not a notarized version of the application.

32 bits version for Windows can also be found in the same place.

Debian Bookworm and Bullseye (32 and 64 bits) can be installed from my repo.

Regards
Xav'

[p001]

I have noticed for a long time that keyboard shortcuts are saved on one computer, and reset on the other.
Sometimes it does not save when assigned, the drawing is attached. Saves it after restarting the program.
Windows 10.

What did I do:
1. Installed codeblocks-20.03;
2. Copied and replaced files from this theme.

[p001]

the same without installing codeblocks-20.03

[eckard_klotz]

Dear All.

Thanks to all developers for the ongoing effort in the further development of Code::Blocks.

After some month I decided use the new nightly 13344 (01.09.2023) to update Code::Blocks from the version used before 13107 (10.12.2022)

Unfortunately, I had to face an issue again, that I have already reported for the nightly 22.01.2022 (12672) here:
https://forums.codeblocks.org/index.php/topic,24820.msg169254.html#msg169254.

Code::Blocks is not able to recognize the compiler tool-chain configuration done in the conf-file by using global variables.
Please see the attached zip-file for the current screenshots:

• MinGW_12_2_0_64msvc_MSYS.conf : the conf-file I choose by using the personality dialogue.
• CB_13344_compilers_autodetection.png: the first information page I get now regarding the missing compiler tool suit.
• CB_13344_compiler_toolchain_executables.png: the partly overwritten list of build-tools actualy completly filed with global variables.
• CB_13159_compiler_toolchain_executables.png: the correct ist of build-tools filed with global variables.

As mentioned the same issue was already reported by me 22.01.2022 (12672).  You have solved the issue with the nightly from 06.02.2022 (12705).
Thus, I hope the description there is detailed enough  and I don't have to repeat it here again. However, don't hesitate to ask me for details you miss.


I tested some older releases between 13107 and 13344 to figure out when the issue was introduced again:

• 13344 bug is present
• 13268 bug is present
• 13231 bug is present
• 13166 bug is present
• 13159 works as desired
• 13107 works as desired

Thus I assume that the issue was introduced again between the revision 13159 (22.01.2023) and the revision 13166 (29.01.2023).


By the way: I'm working with windows 10 (frequently updated) on a laptop.

Best Regards,
                     Eckard Klotz.

[Miguel Gimenez]

Thank you for reporting and the exhaustive information.

Commits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

[stahta01]

Thank you for reporting and the exhaustive information.

Commits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

Based on the images; I am guessing the compiler auto detection is the problem area; instead of the global variable area.

Tim S.

[AndyJ]

Not specifically related to this nightly but I've recent moved from Windows 7 to 10 and now find that when remote debugging using either the J-Link or MCULink tools I can't stop a debug session reliably. Most of the time I get the message:

Trying to interrupt the process by sending CTRL-C event to the console!
Interrupting debugger failed

Using the same tools on Windows 7 things work as expected. I've tried several Win10 machines but they all seem to behave the same but Win7 machines seem fine. This has been going on for the last few nightlys and I've tried re-installing and updating the debugger/GDBservers.

Any thoughts?

[Miguel Gimenez]

Ticket 1353 refers to this issue.

I will update the ticket with your W7 vs W10 comment.

[AndyJ]

Thank you for the information. Has this really been broken since 2019?

I tried to download the nearest nightly that I could find before 11858 for some testing which was 11825 but unfortunately the wxWidgets files seem to be missing.

Is it possible to revert 11858 from nightly builds until a proper fix is found?

Thanks for the help!

[Miguel Gimenez]

Is it possible to revert 11858 from nightly builds until a proper fix is found?

I do not know, and the debugger plugin maintainer is no longer around. Look at the plugin history after that commit or just revert it.

[eckard_klotz]

Hello Miguel Gimenez and Tim.S.

Please accept my apologize for my late reply.

Commits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

I have tested it today again.

• I can confirm, it is working with the nightly from the 22.01.2023 (13159) and it is not working with the nightly from the 29.01.2023 (13166) .
• Please refer the 2 screen shots in the attached zip-file:
  
  • CB_13159_compiler_toolchain_executables.png
  • CB_13166_compiler_toolchain_executables.png

Actually I download every nightly. But for some reasons I don't change always to the newest one.

• The attached zip-file provides a screen shot from my nightly root-directory:
  
  • NightlyFolderRoot.png
• The highlighted folders were tested by me to figure out when the issue occurred.

Based on the images; I am guessing the compiler auto detection is the problem area; instead of the global variable area.

This sounds plausible since the auto-detection warning-dialogue occurs always while starting Code::Blocks when the issue is present.

• However this was the case last year also.
• The attached zip-file provides a screen shot from my MinGW root-directory
  
  • MinGWFolderRoot.png
• As you can see, I don't use the traditional root-directory for the build-suite.
  
  • But I use an own root-directory parallel to other development tools.
  • Furthermore, I provided more than one version and flavour.
  • Thus, the auto-detection would always fail in my case.
• I use different personalities (defined in different conf-files) to choose the version and flavour to work with while starting Code::Blocks.
• Thus, I would expect that Code::Blocks is checking the paths configured in the global variables to use the build-tools configured there.
• If the tool-chain configuration is referring to global variables than Code::Blocks may check if they are validly configured.
• But if one of the global variable is not validly defined, than it is the responsibility of the user to correct its definition.
• However, Code::Blocks replaces the global variable by standard tool-names, what should not be done from my understanding.
• In my case the global variables are referring to valid build-suite locations.
• This means a valid configuration will be replaced by an invalid one.

Nevertheless, please have a nice weekend.

Best regards,
                    Eckard Klotz.

[Miguel Gimenez]

I have just created ticket 1420.

[Miguel Gimenez]

Should be fixed in r13375.