Recent Posts

1

Development / Re: special handling of the macro replacement ""?

« Last post by gd_on on Today at 05:54:21 pm »

To add some informations:
In standard cbp files, there is an environment variable defined as:

Code

<Variable name="WX_CFG" value="" />

When it is used in standard cbp files, as:

Code

<Add directory="$(#wx33_64.lib)/gcc_dll$(WX_CFG)

there are no problems.

In my unified workspace/cbp files, I define a wxwidgets path as, in my case, C:\wxWidgets-3.3.1 as the base, and in a user-defined field, I have created a wx_cfg variable. If I set this variable with nothing (an empty field), the variable is eliminated after a click on the save button. It's why, as in standard cbp files, I tried to set an empty string by "". Apparently, this is the problem described by ollydbg when I use a variable as:

Code

<Add directory="$(#WXWIDGETS)/lib/gcc_dll$(#WXWIDGETS.WX_CFG)

2

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Today at 02:40:13 pm »

I first found a workaround patch, see here:

* wxSmith: workaround an assert issue happens when showing  asmwarrior/codeblocks_sfmirror@e627289

Tested and it won't crash/assert now.

But this is only a workaround, should find a better way.

3

Development / Re: special handling of the macro replacement ""?

« Last post by ollydbg on Today at 09:33:30 am »

Make sure you get approval by MortenMacFlybefore making any changes. Check out the SF tickets for posts on macro and hopefully you will fins the ticket and have a read before you spend time on this as you may end up wasting your time.
BTW I agree with you.

Hi, AndrewCot,  long time no see.
I think it is a good direction.
Maybe there are similar topics in the sourceforge tickets.
So I will search for that.

To switch between the debug version of wx library,  using the unified workspace or cbp project is much easier.  We don't need to replace or editor each cbp files.

4

Development / Re: special handling of the macro replacement ""?

« Last post by AndrewCot on Today at 09:21:14 am »

Make sure you get approval by MortenMacFlybefore making any changes. Check out the SF tickets for posts on macro and hopefully you will fins the ticket and have a read before you spend time on this as you may end up wasting your time.
BTW I agree with you.

5

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Today at 08:41:34 am »

With the help of some AI, I think I have got the idea, but I'm not tested yet.

See here:

https://github.com/wxWidgets/wxWidgets/issues/26108#issuecomment-3809535580

It looks like we have to set a member variable in the override functions.

BTW: VZ(wx developer) just thought that the crash should not happen, but In my test case, if run without the debugger, the assert just cause the crash, not sure why. Any ideas?

6

Development / special handling of the macro replacement ""?

« Last post by ollydbg on Today at 06:43:08 am »

Hi, when I'm using the gd_on's unified workspace/code::blocks cbp files, I see something strange.

See here: it looks like GCC works OK, but GDB failed to find the dll(setting wrong PATH)

Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

If a variable a has a filed name b, and its value is

Code

""

, and if we have

Code

AAA$(#a.b)

, we will finally get

Code

AAA""

The current implementation treats an empty string "" as a valid value and performs the replacement, resulting in

Code

AAA""

instead of the expected

Code

AAA

.

I'd like to see your options on this issue.

Thanks.

7

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Yesterday at 08:26:48 am »

Code

#if WXWIN_COMPATIBILITY_3_2
// By call to obsolete function we want to check if user-overriden function is still in use
wxString wxPGProperty::ValueToStringWithCheck(wxVariant& variant, wxPGPropValFormatFlags flags) const
{
    m_oldValueToStringCalled = false;
    wxString res = ValueToString(variant, static_cast<int>(flags));
    if ( m_oldValueToStringCalled )
    {
        // Our own function was called - this implies that call was forwarded to the new overriding
        // function and there is no need to call it explicitly.
    }
    else
    {   // User-overriden obsolete function was called
        wxFAIL_MSG(wxString::Format("in %s use ValueToString with 'flags' argument as wxPGPropValFormatFlags", GetClassInfo()->GetClassName()));
    }
    return res;
}
#endif // WXWIN_COMPATIBILITY_3_2

In the call stack frame 2, this function always cause assert, do you see this? I have update comments in github issue: https://github.com/wxWidgets/wxWidgets/issues/26108#issuecomment-3803542263

8

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Yesterday at 08:11:28 am »

Not extensivety tested, but it looks OK : wxs files are opened without crash.
Thanks

I try to build a debug version of wx 3.3.1 library, and later build C::B against this library.

When I try to run the debugging, I see this:

Code

Active debugger config: GDB/CDB debugger:Default
Selecting target: 
src
Adding source dir: F:\code\codeblocks-src\codeblocks_sfmirror\src\
Adding source dir: F:\code\codeblocks-src\codeblocks_sfmirror\src\
Adding file: F:\code\codeblocks-src\codeblocks_sfmirror\src\devel33_64\codeblocks.exe
Changing directory to: F:/code/codeblocks-src/codeblocks_sfmirror/src/devel33_64
Set variable: PATH=.;F:\code\wxWidgets-3.3.1\lib\gcc_dll"";F:\code\codeblocks-src\codeblocks_sfmirror\src\devel33_64;F:\code\codeblocks-src\codeblocks_sfmirror\src\exchndl\win64\lib;...

Then, it said the wx dll can't be find, so the debugee C::B can't started.

But if you looked at this:

Code

F:\code\wxWidgets-3.3.1\lib\gcc_dll""

You see the trailing quotes, this quotes come from some global compiler variable those values are "".
It works OK when in compiling, I see such things when compiling:

Code

[100.0%] g++.exe -shared  -Wl,--out-implib=devel33_64\libcodeblocks.a -Wl,--dll 
-LF:\code\wxWidgets-3.3.1\lib\gcc_dll"" 
-Ldevel33_64 

Now, here is the crash call stack, I put it in the txt file in attachment.

9

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Yesterday at 03:53:19 am »

I think I have reported the same issue here in 2025-09, see this post:

Re: code::blocks hangs at startup

So, this issue lasts for a long time.

10

Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1

« Last post by ollydbg on Yesterday at 02:37:27 am »

Not extensivety tested, but it looks OK : wxs files are opened without crash.
Thanks

Strange, I just replaced my local the file: wxscolourproperty.cpp, but the result C::B still crash with the same issue.