Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
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
2
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.


3
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.
4
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.
5
Not extensively tested, but it looks OK : wxs files are opened without crash.
Thanks
6
Try this file (rename as cpp). It may need some adjustment to compile on wx3.3.
7
This method, defined in wxscolourproperty.cpp:152
Code
    wxString wxsMyColourPropertyClass::ValueToString( wxVariant& value,  int argFlags ) const
does not override in wx >= 3.3.0 because the second parameter is no longer an integer, see the documentation.

EDIT: Adding "override" to the declaration would have uncovered this long ago.
8
It looks like the C::B try to read some string values to "reconstruct" the prop grid when reading the wxs file.

But the "string value" maybe empty or not correct, so wx just report the assert.

My guess is that the issue is inside the wxWidgets' library code, not in the C::B's source code.
9
You can try something like this (untested):
Code
#if wxCHECK_VERSION(3, 3, 0)
        VALUE.m_colour = wxColour(_T("rgb")+Id->GetValueAsString(wxPGPropValFormatFlags::Null));
#else
        VALUE.m_colour = wxColour(_T("rgb")+Id->GetValueAsString());
#endif

I just apply this patch, and I see the result C::B still crashed when I open a wxsmith file. :(
10
I think I have the same problem.
I tried your patch in wxscolourproperty.cpp, but no difference. Still a crash when I try to open a wxsmith old file. I obtain an rpt file if this can help.
Before the crash, I can see that a new tab is open in the editor, but it has a name like Untitled0.
Hi, thanks for the test. I just looked at the crash report file, and it is the same crash call stack as mine.
Pages: [1] 2 3 4 5 6 ... 10