61
General (but related to Code::Blocks) / Re: Generate a file '*_linux.cbp' to '*_win.cbp' or vice versa
« Last post by Miguel Gimenez on April 24, 2026, 10:09:10 am »Badly hidden spam reported to moderator.
News:
The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .
Recent Posts
62
my advice: don't use pcm.
I have several projects using C++23 in CB, even C++26.
Quote
PCM as in Precompiled Modules in C++26 (the upcoming C++ standard)
63
General (but related to Code::Blocks) / Re: Generate a file '*_linux.cbp' to '*_win.cbp' or vice versa
« Last post by Miguel Gimenez on April 23, 2026, 09:05:57 am »Delayed profile spammer predictbong reported to moderator.
64
Help / Re: c++23
« Last post by Miguel Gimenez on April 23, 2026, 09:03:23 am »Delayed profile spammer rundowndrag reported to moderator.
65
Help / Re: Code editor window closing after saving files (related to very large projects)
« Last post by Stratelier on April 23, 2026, 02:03:11 am »Oh I've definitely encountered "memory thrashing" before (starting around >90% RAM usage), but when it happens it is typically far worse than what I'm seeing here with CB.
As for ordinary day-to-day usage, I know this bug cast a rather bad first impression of the editor, but I'm also noticing various little mundane details that don't sit as well with me. Like the top-level split between .c and .h files in the project panel.
I'm willing to help stay and debug for a bit, but I'd probably need instruction on building CB from its source first because as long as I'm the only one it's actively happening to, I'm also the only one that can truly dive into it to research what is going wrong where.
If I have two files open & modified, the "save changes?" prompt is a good breakpoint where I should be able to fetch the call stack and find exactly WHERE it is trying to close the editor window.
In the meantime, viewing Task Manager there is a "normal" CPU spike while saving a file (in 1 of 4 CPU cores) but it is very localized to CB itself (not affecting other processes / system at large). I additionally sometimes see the little "leaf" icon next to its status, indicating that (as a UWP process) the system has occasionally suspended it (by force?) -- see attachment.
As for ordinary day-to-day usage, I know this bug cast a rather bad first impression of the editor, but I'm also noticing various little mundane details that don't sit as well with me. Like the top-level split between .c and .h files in the project panel.
I'm willing to help stay and debug for a bit, but I'd probably need instruction on building CB from its source first because as long as I'm the only one it's actively happening to, I'm also the only one that can truly dive into it to research what is going wrong where.
Quote
I can find no code that saves the files ok and then closes them.
If I have two files open & modified, the "save changes?" prompt is a good breakpoint where I should be able to fetch the call stack and find exactly WHERE it is trying to close the editor window.
In the meantime, viewing Task Manager there is a "normal" CPU spike while saving a file (in 1 of 4 CPU cores) but it is very localized to CB itself (not affecting other processes / system at large). I additionally sometimes see the little "leaf" icon next to its status, indicating that (as a UWP process) the system has occasionally suspended it (by force?) -- see attachment.
66
my advice: don't use pcm.
I have several projects using C++23 in CB, even C++26.
I have several projects using C++23 in CB, even C++26.
67
General (but related to Code::Blocks) / Re: Generate a file '*_linux.cbp' to '*_win.cbp' or vice versa
« Last post by Miguel Gimenez on April 22, 2026, 11:44:29 am »Profile spammer olenna reported to moderator.
68
Help / Re: Cannot find the compiler
« Last post by thereforerepair on April 22, 2026, 10:17:41 am »Go to Settings -> Compiler, select the "Toolchain executables" tab and fill the controls with your compiler's location (use where gcc.exe in the cmd prompt) and program's names.
Great! The instructions shared are accurate. Executing the correct command is crucial to ensuring the program works and runs.
69
Help / Re: Code editor window closing after saving files (related to very large projects)
« Last post by Pecan on April 19, 2026, 08:19:18 pm »I have run CB 20.05 in vmware with a memory size of 4gig and was unable to get the file closes on save that Stratelier gets.
I did experience the memory thrashing during a file save when memory usage reached 91%.
I ran CB under the debugger and chased high memory usage happening when scintilla double buffered the file. There was sometimes a near 10 second pause of the whole system.
Most likely memory thrashing.
I was unable to determine how files were closed when they were saved ok.
If they were not saved ok, we should have seen the message from this function:
I can only guess that this is some kind of physical memory error or that the stack got corrupted and the code returned to the wrong place.
I can find no code that saves the files ok and then closes them.
I did experience the memory thrashing during a file save when memory usage reached 91%.
I ran CB under the debugger and chased high memory usage happening when scintilla double buffered the file. There was sometimes a near 10 second pause of the whole system.
Most likely memory thrashing.
I was unable to determine how files were closed when they were saved ok.
If they were not saved ok, we should have seen the message from this function:
Code
if (!cbSaveToFile(m_Filename, m_pControl->GetText(), GetEncoding(), GetUseBom(), robustSave))
{
wxString msg;
msg.Printf(_("File %s could not be saved..."), GetFilename().c_str());
cbMessageBox(msg, _("Error saving file"), wxICON_ERROR);
return false; // failed; file is read-only?
}
I can only guess that this is some kind of physical memory error or that the stack got corrupted and the code returned to the wrong place.
I can find no code that saves the files ok and then closes them.
70
Help / Re: Why does the code editor window close after saving a file?
« Last post by Stratelier on April 19, 2026, 01:17:25 am »Sorry. At the time I was following the instructions from developer.gimp.org (and there are quite a few more for Windows than on Linux), one of which is to fetch it via git command-line.
The issue does seem specifically related to very large projects, as I cannot reproduce it in isolated files or "hello world" sized projects.
As for my system: A laptop from 2014 with 4GB shared RAM. It has room for 8 to 16GB but the RAM sockets are the last thing in the teardown (ugh). So it tends to be under a bit of stress.
The issue does seem specifically related to very large projects, as I cannot reproduce it in isolated files or "hello world" sized projects.
As for my system: A laptop from 2014 with 4GB shared RAM. It has room for 8 to 16GB but the RAM sockets are the last thing in the teardown (ugh). So it tends to be under a bit of stress.