Recent Posts

11

Using Code::Blocks / Re: Help getting SDL2 to work in Code Blocks

« Last post by smithjohns on November 04, 2025, 07:53:03 am »

I'm new to programming, and very frustrated with IDEs.
I'm running MX Linux (Debian based).
I can compile successfully with: $ gcc -o main main.c `pkg-config --cflags --libs sdl2, SDL2_image`
But how do I configure CodeBlocks use the same command??? (or at least achieve the same result).
I would appreciate some DETAILED help.
Assignment Help

You can set the compiler and linker flags in Code::Blocks under Project → Build Options → Compiler and Linker Settings. Just copy the flags from your gcc command there.

12

Using Code::Blocks / Re: Problem with standalone exe

« Last post by nenin on November 04, 2025, 07:47:55 am »

Surely somebody knows what all those different 'compliers' are and what the difference is?

I know. It is different compilers for the different cases. I have 3 compilers in use: one for Win64 (gcc 14.2, default), one for Win32 (gcc 14.2 for some automation tasks, old hardware has no Win64 drivers) and one for XP (gcc 9.3, really old hardware, no Win7 drivers).

13

Development / Re: AI may help us to create plugins

« Last post by HangNickHers on November 03, 2025, 11:44:56 pm »

It's good to see reasonable posts.
Anyway I went to see that website linked there, putting all aversion aside for a moment.
Disgusting. What a bunch of trash. Again, this is the type of thing that actual developers should spend time doing -- proper documentation. Graphs, diagrams, file names, descriptions of classes and methods, are helpful. And so forth. Should have been somewhere since the beginning, or, for a long time anyway.
Anyone wishing to contribute should take the necessary time to study the project, and understand it. Obviously.

Before adding yet more cruft, I'd favour fixing bugs in cb.

This. So, another project I've liked for years, called Lazarus, an excellent free Pascal IDE, had the same garbage discussed for quite some time. A bunch of idiots suggesting AI this, AI that, left and right. Instead of spending energy on what really matters. New releases, same problems.

Despite the slightly agressive response, I fully agree that AI is ruining a lot of things, e.g. localhost being broken in Windows 11 and worse.

I thought it was a joke, but I read about a "copilot" on Windows 11's Notepad, and it's real. Again, it should be clear what their goals are: to turn users into even greater morons. Lazy and dumb and incompetent. The cattle are given slop. And they swallow it all and enjoy it and praise it and tell others how great it all is and how they should eat it as well.

So I got banned without any warnings, and my two posts deleted, because of that post.

It's nothing new. Nothing but garbage to attract lazy, stupid, incompetent people.
It's an often an excuse to be a moron. As blauzahn observed, to flee accoutability as well. I've seen "The AI wrote it" and such. (No, YOU commited low-effort, barely functional garbage.)
You'd expect programmers to know better, but, you see how it is now.

14

Nightly builds / Re: The 25 October 2025 build (13754) is out.

« Last post by blauzahn on November 03, 2025, 08:30:03 pm »

Thank you, Lieven.

15

Development / Re: AI may help us to create plugins

« Last post by blauzahn on November 03, 2025, 08:27:13 pm »

I'd also vote against, regardless of how tempting it might sound.

Using AI as inspiration or as lightning quick "seems to work" hack is fine as long as you resist the huge temptation to cut-copy-paste any single line of code you do not fully understand. Remember: As soon as you change/add anything, the responsability and maintenance becomes essentially yours, not the AI's.

Before adding yet more cruft, I'd favour fixing bugs in cb.

Finding potential memory leaks in cb can be done on Linux with e.g. cppcheck, scan-build, heaptrack or valgrind --- or just look for raw new in the editor and you'll quickly find a few good candidates.
Use a more modern programming style and you put in hardly any leak in the first place. Granted, legacy frameworks may limit its scope.

16

Help / Re: Different handling of placeholders

« Last post by blauzahn on November 03, 2025, 07:55:50 pm »

Maybe because macro expansion is better used reluctantly? Like minimizing the usage of the c-preprocessor.  Currently, I do not use default-code but I would be fine with how it is as you described.

I briefly searched cb-source for default-code. The function that expands placeholders is in trunk/src/sdk/editormanager.cpp:495

Code

cbEditor* EditorManager::New(const wxString& newFileName)
{
//    wxString old_title = Manager::Get()->GetAppWindow()->GetTitle(); // Fix for Bug #1389450
    // create a dummy file
    if (!newFileName.IsEmpty() && !wxFileExists(newFileName) && wxDirExists(wxPathOnly(newFileName)))
    {
        wxFile f(newFileName, wxFile::write);
        if (!f.IsOpened())
            return nullptr;
    }
    cbEditor* ed = new cbEditor(m_pNotebook, newFileName, m_Theme);
//    if ((newFileName.IsEmpty() && !ed->SaveAs()) || !ed->Save())
//    {
//        //DeletePage(ed->GetPageIndex());
//        ed->Destroy();
//        Manager::Get()->GetAppWindow()->SetTitle(old_title); // Though I can't reproduce the bug, this does no harm
//        return 0;
//    }

    // add default text
    wxString key;
    key.Printf(_T("/default_code/set%d"), (int)FileTypeOf(ed->GetFilename()));
    wxString code = Manager::Get()->GetConfigManager(_T("editor"))->Read(key, wxEmptyString);
    // Allow usage of macros
    // TODO (Morten#5#): Is it worth making this configurable?!
    Manager::Get()->GetMacrosManager()->ReplaceMacros(code);
    ed->GetControl()->SetText(code);

    ed->SetColourSet(m_Theme);
    AddEditorBase(ed);

    ed->Show(true);
    SetActiveEditor(ed);

    CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, nullptr, ed);
    Manager::Get()->GetPluginManager()->NotifyPlugins(evt);

    return ed;
}

see the lines:

Code

    // Allow usage of macros
    // TODO (Morten#5#): Is it worth making this configurable?!
    Manager::Get()->GetMacrosManager()->ReplaceMacros(code);

Apart from that snippet, at first glance, I did not find in the source code any further rationale for the decision you asked for.

The code entered into the settings dialog can be found in ~/.config/codeblocks/default.con. Please search for default_code within that file.

Why do you want the creation date of a source file in the first place? I'd rather look up in version control when it was added. With that username, do you do that for legal reasons?

17

Development / Re: AI may help us to create plugins

« Last post by Михаил Агарков on November 03, 2025, 06:18:31 pm »

Well no kidding?! Who would've thunk?!
You know what could help us create plugins? Or create anything at all? Capable programmers.
This isn't helping. What's even the point of bringing up that crap? Seriously.
Look at the state of this project. How many people have been contributing? How many stable releases in the past eight years?
Last thing we need is incompetent scum "contributing" computer-generated garbage to any part of Code::Blocks. 
Well, if you guys want to kill it, then go ahead, suggest AI usage -- nay, even better, make AI plugins, an assistant on the IDE itself. A COPILOT integrated to it! Imagine that! Wouldn't that be great?
And not long ago we didn't even have a functional Symbols Browser. To be removed completely on a newer release. What a joke.
And people wonder why some things are as they are.
Listen to yourself, look around you, look at the project, look around it, then listen to yourself again, and think.
And you just threw Code::Blocks' source code into some garbage bin? Really, projects must have some sort of protection against this kind of stupidity, these days.
Then again, I don't know what's the goal exactly, but, if you guys are planning to turn this into a huge pile of crap, then disregard what I'm saying.
Thanks.

Despite the slightly agressive response, I fully agree that AI is ruining a lot of things, e.g. localhost being broken in Windows 11 and worse.
The reason I love Code::Blocks is that it doesn't use overbloated JS frameworks with Electron, it uses native GUI controls and has a very nice feature set, like wxSmith and so much more.
I also don't want Code::Blocks to fallback on using AI to generate code, because it would very likely break things, god forbid it from using web technologies and take up hundreds of megabytes of RAM being idle just to have Copilot. I love this IDE because it just works, has an amazing feature set and can even work on Windows XP and ReactOS with no lag on old hardware.
If it were to introduce AI, I would very likely create a hard fork just for myself and anyone else interested.

18

Help / Different handling of placeholders

« Last post by rechtsanwaltsteyer on November 03, 2025, 11:07:18 am »

Hello everyone,
her my until now unresponded question again:
Since version 20.03 and also in the current version 25.03, I have an unsolvable problem:
1. If I enter a placeholder under Settings/Editor/Code Specification, such as "$(NOW_L)", the current date and time is displayed in the subsequently generated single file (*.cpp/*.h).
2. However, if I enter the same placeholders in /usr/share/codeblocks/templates/wizard/console/cpp/main.cpp, when generating a new project, "$(NOW_L)" is displayed in main.cpp instead of the current date and time.
My question: Why this different treatment of "$(NOW_L)?"
Thank you in advance!
Michael

19

General (but related to Code::Blocks) / Re: forums.codeblocks.org Cert has expired

« Last post by sodev on November 02, 2025, 04:52:39 pm »

So you are saying that cert's should be okay after the expiry? I disagree and my second post was a reminder that the admin needs to keep any eye on the 3 monthly lets encrypt expiry.

No i don't, expired certificates do not work. Usually the certificates are managed by Certbot, it schedules a cron job (or whatever system the OS uses) to check the certificates daily and acquire and install new ones automatically when the current ones are about to expire.

20

Development / Re: C::B 25.03 Multiple Debuggers selection old bug still there.

« Last post by Pecan on November 02, 2025, 02:10:31 am »

But then, the ability to choose Debugger in a "Compiler Settings" makes no sense.

As I remember, in earlier versions, the current debugger was selected by selecting the "Build target" to build, and in a "Build Options" the compiler is selected, and in a "Compiler setting" is a debugger defined for that particular compiler.

It is a bit misleading to have separate Build target selection and Debugger selection, along with the ability to set debugger in a "Compiler settings", that has no effect then.

Yeah, there's been some fiddling around in that area of the code. But that fiddler is no longer around.

Could you just copy some of this thread and make a ticket of it.
I'm working on debugger_DAP and if/when I get into that area and fix it, I'll make a backport also.

Thanks