51
Using Code::Blocks / Re: Interest in a CMake Solution Generator for Code::Blocks via cmake-file-api?
« Last post by Suryavarman on August 17, 2026, 03:07:29 pm »Nice.
News:
As usual while waiting for the next release - don't forget to check the nightly builds in the forum.
Recent Posts
52
Development / Re: Assertion on closing codeblocks due to wxWidgets 3.3
« Last post by Miguel Gimenez on August 17, 2026, 02:28:37 pm »There is a similar issue, see wxTreeCtrl::GetFirstVisibleItem() returns invisible item on MSW if the tree is hidden. I added an item visibility check to avoid an assertion when the project tree was hidden on project loading.
53
Help / Re: The tabs close when you save a file.
« Last post by Miguel Gimenez on August 17, 2026, 01:38:39 pm »Workaround for broken range-for added in r13956, thanks Blauzahn.
54
Help / Re: libgcc_s_seh-1.dll
« Last post by gd_on on August 17, 2026, 01:20:28 pm »You can also add the path to this libgcc_s_seh-1.dll, and many other dll in the bin sub folder of your compiler, to your PATH variable, the system one if you are admin or simply the user one.
55
Help / Re: libgcc_s_seh-1.dll
« Last post by everSome on August 17, 2026, 02:43:20 am »I addition to libgcc_s_seh-1.dll, many(all?) g++ compiled programs also bind to libstdc++-6.dll.
You can also just copy them from wherever g++ is located into your D:\C_Plus\test\bin\Debug directory.
You can also just copy them from wherever g++ is located into your D:\C_Plus\test\bin\Debug directory.
56
Help / libgcc_s_seh-1.dll
« Last post by DanShelley on August 16, 2026, 08:24:42 pm »I installed codeblocks 25.03 on my windows 10 64bit machine.
I made a test project and it runs find to show hello world.
When I use explore D:\C_Plus\test\bin\Debug\test.exe and double click
I get this error message cannot find libgcc_s_seh-1.dll
I think path must not be correct.
Any ideas?
I made a test project and it runs find to show hello world.
When I use explore D:\C_Plus\test\bin\Debug\test.exe and double click
I get this error message cannot find libgcc_s_seh-1.dll
I think path must not be correct.
Any ideas?
57
Development / Assertion on closing codeblocks due to wxWidgets 3.3
« Last post by christo on August 16, 2026, 07:34:05 am »There is a regression in wxWidgets causing assertion window on closing codeblocks if the project tree is expanded and is big.
I've reported it to wxWidgets project and fix is identified. https://github.com/wxWidgets/wxWidgets/issues/26839
Code
../src/generic/treectlg.cpp(1539): assert "IsVisible(item)" failed in GetNextVisible(): this item itself should be visibleI've reported it to wxWidgets project and fix is identified. https://github.com/wxWidgets/wxWidgets/issues/26839
58
Using Code::Blocks / Editor : Swap header/source
« Last post by LETARTARE on August 15, 2026, 03:00:59 pm »Leap-15.6
Currently, on a file editor: if you ask to switch to the header/source the requested file opens in an editor all to the right of the open files.
If many files are opened, the layout is incorrectly appropriate.
Is there an option to open it next to the applicant ?
Currently, on a file editor: if you ask to switch to the header/source the requested file opens in an editor all to the right of the open files.
If many files are opened, the layout is incorrectly appropriate.
Is there an option to open it next to the applicant ?
59
Development / Re: wxWidgets version mismatch in About dialog on Linux
« Last post by PB on August 14, 2026, 11:54:23 pm »I see, thanks for the explanation. So basically the same as the compile- and run-time version of GTK reported there.
60
Development / Re: wxWidgets version mismatch in About dialog on Linux
« Last post by Miguel Gimenez on August 14, 2026, 08:17:35 pm »One is the version used to compile C::B, it will not change until a recompilation. The other is the version of the wxWidgets dynamic library used to run C::B, it may change after a system update.
wx3.2.x is special because the library name does not change with version updates, so C::B just uses the new library as they have the same ABI. This mismatch will not happen with wx3.3.x.
wx3.2.x is special because the library name does not change with version updates, so C::B just uses the new library as they have the same ABI. This mismatch will not happen with wx3.3.x.