1
Nightly builds / Re: The 20 July 2026 build (13916) is out.
« Last post by killerbot on Today at 03:21:17 pm »next steps:
- step up to wx 3.3.3
- step up to gcc16
News:
As usual while waiting for the next release - don't forget to check the nightly builds in the forum.
Recent Posts
2
Nightly builds / The 20 July 2026 build (13916) is out.
« Last post by killerbot on Today at 03:20:39 pm »We switched to gcc 15.2.0 (on 09 April 2026) --> download the new wx/mingw dll's see link below
Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/15.2.0posix-14.0.0-ucrt-r7/winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-14.0.0-r7.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/wxmsw33u_gcc_cb_wx332_2D_gcc1520-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls15.2.0.7z
The 20 July 2026 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2026/CB_20260720_rev13916_win64.7z
- Linux :
none
The current SDK version is : 2.25.0
Resolved Fixed:
Regressions/Confirmed/Annoying/Common bugs:
Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/15.2.0posix-14.0.0-ucrt-r7/winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-14.0.0-r7.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/wxmsw33u_gcc_cb_wx332_2D_gcc1520-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls15.2.0.7z
The 20 July 2026 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2026/CB_20260720_rev13916_win64.7z
- Linux :
none
The current SDK version is : 2.25.0
Resolved Fixed:
- SDK: Fix issue loading workspaces with wxWidgets 3.3. This may fix ticket #1605.
- implemented FR from here: https://forums.codeblocks.org/index.php?action=profile;area=showposts;u=54114 to allow changing the line spacing in editors
- autotools: fix build error on Windows (ticket #1608)
- SDK: Show field name of unknown global variables (ticket #1607, thanks homertp).
- Compiler: Do not disable project options for unknown compiler (ticket #1606, thanks homertp).
- wxSmith: Add wxCommandLinkButton to the Standard palette.
- wxSmithAui: Fix gripper selection in wxAuiManager adding missing "break".
- SDK: Fix error window when installing plugins in a user data directory (ticket #1610, thanks homertp).
- Codeblocks: Fix wx3.3.0 asserts caused by wxauibook changes that no longer allow access to wxTabCtrls
- applied a couple of fixes to compile wxCustomControls on wx3.3 and to eliminate compiler warnings
- wxContribItems: Make KWIC/BmpCheckBox actually work and fix integration in wxSmith.
- wxSmith ContribItems: Fix Led and StateLed size and inconsistencies.
- clangd_client Fix crash in parser.cpp when there is no active process and correct warnings re: json.cpp macro spacing
- projectmanager: Avoid Windows/CodeBlocks crash caused by rapid Freeze/Thaw calls when closing large workspaces.
- wxContribItems: Fix lcdwindow initial size.
- CodeBlocks: Fix the unexpanded editor pane when using wx 3.3
- FileManager: Fix assertion "page must be a child of the notebook".
- clangd_client: support refactoring using clangd (textDocument/codeAction)
- SDK: Increase fold margin width in the editor and change it with scale factor.
Regressions/Confirmed/Annoying/Common bugs:
3
Nightly builds / Re: The 27 May 2026 build (13855) is out.
« Last post by eckard_klotz on Today at 12:52:33 pm »Hello Miguel Gimenez.
If you prefer the current margin order but your users not the alternative will be to make the margin order configurable.
But I fear this will mean much more effort for you.
Thus, I just ask you to solve the folding issue and changing the margin order is a simple way to fix the issue without disabling the folding completely.
Best regards,
Eckard Klotz.
Quote
... Relating margin order, I prefer it as is. ...
- It is not the order but the unwanted firing of folding, that is disturbing.
- An unwanted folding means always to breakdown the development-flow.
- Suddenly and unexpected the text-part, you want to edit, is vanishing.
- Instead of of implementing your idea, you have to unfold again.
- Than you have to search for the text-position you wanted to work on.
- Finally, by clicking on it, you risk to fold again.
- I know nobody who is not frustrated by this.
- Moving the folding margin to the left and away from the text area prevents this nasty disturbance.
If you prefer the current margin order but your users not the alternative will be to make the margin order configurable.
But I fear this will mean much more effort for you.
Thus, I just ask you to solve the folding issue and changing the margin order is a simple way to fix the issue without disabling the folding completely.
Best regards,
Eckard Klotz.
4
Development / Re: Multiple declarations/definitions of wxSwitcherDialog
« Last post by Miguel Gimenez on Today at 10:12:15 am »Spam reported to moderator.
5
Development / Re: Multiple declarations/definitions of wxSwitcherDialog
« Last post by AlexMazure on Today at 03:33:45 am »I've been unwinding lately with a puzzle game called Block Blast. There's something so satisfying about clearing rows and keeping the board from filling up. It's a great way to focus. Speaking of unique implementations, what are your thoughts on handling similar class names in different contexts?
6
General (but related to Code::Blocks) / Re: Delete a ticket on 'CodeBlocks/Tickets'
« Last post by LETARTARE on Yesterday at 11:24:19 pm »Thanks
7
General (but related to Code::Blocks) / Re: Delete a ticket on 'CodeBlocks/Tickets'
« Last post by Miguel Gimenez on Yesterday at 09:06:26 pm »Deleted.
8
Nightly builds / Re: The 27 May 2026 build (13855) is out.
« Last post by Miguel Gimenez on Yesterday at 08:55:51 pm »I have increased margin size from 16 to 22 and made it dependent on scale factor, see r13915.
EDIT: Clicking in the gap between the fold box and the text editor still fires folding
, so this change only fixes box size in HiDPI. Relating margin order, I prefer it as is.
EDIT: Clicking in the gap between the fold box and the text editor still fires folding
, so this change only fixes box size in HiDPI. Relating margin order, I prefer it as is.9
Nightly builds / Re: The 27 May 2026 build (13855) is out.
« Last post by eckard_klotz on July 18, 2026, 12:35:10 pm »Hello Developers.
Unfortunately the folding margin is located next to the text inside the editor and thus, it happens very easily that you force a folding even you just want click at the first line position, what is very annoying.
While reviewing the current margin configuration in cbEditor.cpp, I noticed that Code::Blocks defines its own margin IDs:
As far as I understand it, Scintilla (and wxScintilla) always render margins strictly in ascending ID order.
Because of this, the folding margin (ID 3) appears directly next to the text area in the editor. This placement makes it easy to accidentally trigger fold/unfold actions when clicking near column 1, especially on high‑resolution displays.
Other Scintilla‑based editors (SciTE, Geany, Notepad++) avoid this issue by placing the folding margin immediately to the right of the line‑number margin. This provides a natural buffer zone and significantly reduces accidental folding.
In Code::Blocks, the folding margin is configured here:
Since all margin‑related logic consistently seems to use the symbolic constants (C_FOLDING_MARGIN, C_MARKER_MARGIN, etc.), adjusting the margin order is limited to changing the four #define values. No other code changes should be required, and no plugins or configuration files are affected.
Suggested improvement:
Reassign the folding margin to a lower ID (e.g., 1), so the margin order becomes:
Line numbers → Folding → Marker → Changebar → Text
This can simply be changed while the definition of the preprocessor constants like this:
I think this small, isolated change would align Code::Blocks with common Scintilla practice and improve usability without introducing new settings or breaking existing functionality.
Please take a look to this and thank you in advance.
Best regards,
Eckard Klotz.
Unfortunately the folding margin is located next to the text inside the editor and thus, it happens very easily that you force a folding even you just want click at the first line position, what is very annoying.
While reviewing the current margin configuration in cbEditor.cpp, I noticed that Code::Blocks defines its own margin IDs:
Code
#define C_LINE_MARGIN 0
#define C_MARKER_MARGIN 1
#define C_CHANGEBAR_MARGIN 2
#define C_FOLDING_MARGIN 3
As far as I understand it, Scintilla (and wxScintilla) always render margins strictly in ascending ID order.
Because of this, the folding margin (ID 3) appears directly next to the text area in the editor. This placement makes it easy to accidentally trigger fold/unfold actions when clicking near column 1, especially on high‑resolution displays.
Other Scintilla‑based editors (SciTE, Geany, Notepad++) avoid this issue by placing the folding margin immediately to the right of the line‑number margin. This provides a natural buffer zone and significantly reduces accidental folding.
In Code::Blocks, the folding margin is configured here:
Code
control->SetMarginType(C_FOLDING_MARGIN, wxSCI_MARGIN_SYMBOL);
control->SetMarginWidth(C_FOLDING_MARGIN, foldingMarginBaseWidth);
control->SetMarginMask(C_FOLDING_MARGIN, ...);
control->SetMarginSensitive(C_FOLDING_MARGIN, 1);
Since all margin‑related logic consistently seems to use the symbolic constants (C_FOLDING_MARGIN, C_MARKER_MARGIN, etc.), adjusting the margin order is limited to changing the four #define values. No other code changes should be required, and no plugins or configuration files are affected.
Suggested improvement:
Reassign the folding margin to a lower ID (e.g., 1), so the margin order becomes:
Line numbers → Folding → Marker → Changebar → Text
This can simply be changed while the definition of the preprocessor constants like this:
Code
#define C_LINE_MARGIN 0
#define C_FOLDING_MARGIN 1
#define C_MARKER_MARGIN 2
#define C_CHANGEBAR_MARGIN 3
I think this small, isolated change would align Code::Blocks with common Scintilla practice and improve usability without introducing new settings or breaking existing functionality.
Please take a look to this and thank you in advance.
Best regards,
Eckard Klotz.
10
General (but related to Code::Blocks) / Re: Delete a ticket on 'CodeBlocks/Tickets'
« Last post by LETARTARE on July 18, 2026, 11:11:22 am »Thanks :
992
1262
1265
1362
1433
1440
992
1262
1265
1362
1433
1440