Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Nightly builds / Re: The 09 February 2026 build (13785) is out.
« Last post by Xaviou on February 27, 2026, 10:24:15 pm »
Hi
EDIT:
The solution recommended by Gemini is the same but using "unsigned int"
Code
BindMethod(v, _SC("GetAlpha"), NoParamGetterInt<unsigned int, wxColour, &wxColour::GetAlpha>, _SC("wxColour::GetAlpha"));

Well : I've also submitted the problem to an AI (Claude via the Codex extension of VSCode)  :-[ : it gave me a more complex solution (tested with rev 13793 and it worked) :

He told me to add 4 new functions (near other wrappers wxColour, for example, after wxColour_To_String) :
Code
SQInteger wxColour_Blue(HSQUIRRELVM v)
{
    ExtractParams1<const wxColour*> extractor(v);
    if (!extractor.Process("wxColour_Blue"))
        return extractor.ErrorMessage();
    sq_pushinteger(v, extractor.p0->Blue());
    return 1;
}

SQInteger wxColour_Green(HSQUIRRELVM v)
{
    ExtractParams1<const wxColour*> extractor(v);
    if (!extractor.Process("wxColour_Green"))
        return extractor.ErrorMessage();
    sq_pushinteger(v, extractor.p0->Green());
    return 1;
}

SQInteger wxColour_Red(HSQUIRRELVM v)
{
    ExtractParams1<const wxColour*> extractor(v);
    if (!extractor.Process("wxColour_Red"))
        return extractor.ErrorMessage();
    sq_pushinteger(v, extractor.p0->Red());
    return 1;
}

SQInteger wxColour_Alpha(HSQUIRRELVM v)
{
    ExtractParams1<const wxColour*> extractor(v);
    if (!extractor.Process("wxColour_Alpha"))
        return extractor.ErrorMessage();
    sq_pushinteger(v, extractor.p0->Alpha());
    return 1;
}
And then, replacing the 4 "BindMethod" witch were causing the build error:
Code
BindMethod(v, _SC("Blue"), wxColour_Blue, _SC("wxColour::Blue"));
BindMethod(v, _SC("Green"), wxColour_Green, _SC("wxColour::Green"));
BindMethod(v, _SC("Red"), wxColour_Red, _SC("wxColour::Red"));
BindMethod(v, _SC("Alpha"), wxColour_Alpha, _SC("wxColour::Alpha"));

Regards
Xav'
52
Nightly builds / Re: The 26 February 2026 build (13800) is out.
« Last post by Xaviou on February 27, 2026, 10:10:49 pm »
Hi.

32 bits version for Windows (and also 64 bits version) can be downloaded from my website.
I made both a wxWidgets-3.2.8 and wxWidgets-3.3.1 linked versions

Debian Trixie (64 bits) and Bookworm (32 and 64 bits) can be installed from my repo
The corresponding unsigned deb files can also be downloaded from the website page linked above.

Ubuntu-22.04, 24.10 and 25.10 versions can be installed from my ppa (they are now available for both amd64 and arm64 architectures).

Regards
Xav'
53
Development / Re: svn rev 13798 issue?
« Last post by gd_on on February 27, 2026, 09:39:24 am »
I have seen that inside ....\src\tools\test\macrosmanager there is a macrosmanager.cbp file. It can display variables in the C::B log window if you launch a build or full rebuild command. The display is a little bit heavy/confusing, but it exists!

PS: in some of the clangd_client_wx*.cbp, the $(CODEBLOCKS) variable is still used.
54
Development / Re: svn rev 13798 issue?
« Last post by ollydbg on February 27, 2026, 01:08:51 am »
I've reverted the use of built-in variables in the codesnippets.cbp.

Sadly, this means we can never  use the built-in macros in a .cbp file.

Hello pecan, thanks for the fix.

I think basically linking the recent built plugin to the host CB has another issue. Sometimes
the host CB and the client CB have different SDK numbers, I'm just avoid doing that.

About print the Macro values,  Maybe we can have a Squirrel script to print all those values.

55
Development / Re: svn rev 13798 issue?
« Last post by Pecan on February 26, 2026, 08:05:01 pm »
Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...

Would displaying the built-in vars within Code::Blocks allow us to use them in .cbp files?
Would that avoid the problems experienced by ollydbg?
56
Development / Re: svn rev 13798 issue?
« Last post by Pecan on February 26, 2026, 08:00:30 pm »
I've reverted the use of built-in variables in the codesnippets.cbp.

Sadly, this means we can never  use the built-in macros in a .cbp file.

57
Development / Re: svn rev 13798 issue?
« Last post by Miguel Gimenez on February 26, 2026, 07:44:25 pm »
Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...

I do not think so. There is a MacrosManager::GetMacros() method, currently unused, that would make easy to add this information to a tab in the About dialog (for example). This way the user does not have to search the Wiki.
58
Development / Re: svn rev 13798 issue?
« Last post by gd_on on February 26, 2026, 04:35:34 pm »
Is there a way to display within Code::Blocks the content of environment variables that are set by MacrosManager, so AMP, CODEBLOCKS, APP_PATH, ...
59
Nightly builds / The 26 February 2026 build (13800) is out.
« Last post by killerbot on February 26, 2026, 04:22:56 pm »
We switched to gcc 15.1.0 (on 23 May 2025) --> 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.1.0posix-12.0.0-ucrt-r1/winlibs-x86_64-posix-seh-gcc-15.1.0-mingw-w64ucrt-12.0.0-r1.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_wx328_2D_gcc1510-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls15.1.0.7z


The 26 February 2026 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2026/CB_20260226_rev13800_win64.7z
  - Linux :
   none

The current SDK version is : 2.25.0

Resolved Fixed:

  • Debugger: Really use configured font in watches' tooltips (ticket #1586, thanks pecan/Gemini
  • wxSmith: Allow twildcard translation in wxFilePickerCtr
  • clangd_client: Fix crash in wxRecursionGuard caused by wrong cross-thread protocol

Regressions/Confirmed/Annoying/Common bugs:


    60
    Development / Re: svn rev 13798 issue?
    « Last post by ollydbg on February 26, 2026, 08:48:30 am »
    First, this "CODEBLOCKS" is defined here:

    Code
    void MacrosManager::ClearProjectKeys()
    {
        m_Macros.clear();

        m_Macros[_T("AMP")]        = _T("&");
        m_Macros[_T("CODEBLOCKS")] = m_AppPath;
        m_Macros[_T("APP_PATH")]   = m_AppPath;
        m_Macros[_T("APP-PATH")]   = m_AppPath;
        m_Macros[_T("APPPATH")]    = m_AppPath;
        m_Macros[_T("DATA_PATH")]  = m_DataPath;
        m_Macros[_T("DATA-PATH")]  = m_DataPath;
        m_Macros[_T("DATAPATH")]   = m_DataPath;
        m_Macros[_T("PLUGINS")]    = m_Plugins;
        m_Macros[_T("LANGUAGE")]   = wxLocale::GetLanguageName(wxLocale::GetSystemLanguage());
        m_Macros[_T("ENCODING")]   = wxLocale::GetSystemEncodingName();

    But in my build environment, it can't be used.

    Here is my situations:

    1, I use a C::B(let's say it is the host C::B) to open and build C::B workspace. The build result is the client C::B.
    2, The host C::B is usually download from my github action release which is using the latest release version of wx 3.3.1 and latest msys2, and the C runtime is UCRT.
    3, The client C::B is usually link to the debug version of the wxWidgets. In my local PC, I have build debug version of wx 3.3.1 myself under gcc compiler(msys2, but the C runtime is MSVCRT, because some of my clients are still using Windows 7) to track errors.

    If using $(CODEBLOCKS) method, I have to link the client C::B's plugin against the host C::B, that is not possible. Because they use different wxWidgets library, different GCC version, different C runtime library.
    Pages: 1 2 3 4 5 [6] 7 8 9 10