Recent Posts

51

Nightly builds / Re: The 06 December 2025 build (13761) is out.

« Last post by ChosenName on January 25, 2026, 09:24:36 am »

Whatever tool is used to create the compiler options checklist seems to fail when it encounters a mingw-w64 GCC compiler version that it does not "know", i.e.:
When the selected compiler is reverted to a compiler that the tool "knows" it does not go back to the checklist and stays with the blank tab.

As requested last year when you posted what looks like the same issue can you post instructions on how to re-create this and include the OS and CB version you are using.

My apologies for failing to follow up on my report from last year.

OS: Windows 11, currently update 25H2;
CB: various, currently 13761;

Steps:
1) Compile latest mingw-w64 using MSYS2 and https://github.com/niXman/mingw-builds, in this case based on GCC 15.2;
2) Copy mingw-w64 to location where I keep all of my compilers (based on GCC 10.5, 11.5, 12.5, 13.4, 14.3 & 15.2);
3) Set up the new compiler version option in CB settings (by copying and renaming an existing one as they are adjacent in the list, remembering to set the toolchain executables path);
4) Select new compiler version as a build target in a project;
5) Compile using new compiler version;
6) Close project at end of session;
7) Open project;
8] Observe missing list & checkboxes in compiler flags tab of project build options for all compilers, not just the latest compiler version.

52

Development / Re: wxSmith : add option for Create function in inhereited cases

« Last post by LR83 on January 25, 2026, 09:01:08 am »

Not exactly, in my case it's about inherited classes.
For example, we have a first class that inherits from wxPanel: wxMyPanel. Then a second class that inherits from wxMyPanel with different parameters. For this second class, we don't want to use the Create function but inheritance directly in the constructor.
This is also possible with first class. For example:
Header:

Code

class wxMyPanel: public wxPanel
{
  public:

    wxMyPanel(wxWindow* parent, wxWindowID id);
    virtual ~wxMyPanel();

  protected:
     // Other declarations
};

Code:

Code

wxMyPanel::wxMyPanel(wxWindow* parent, wxWindowID id)
{
  //(*Initialize(wxMyPanel)

  Create(parent, id, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL, _T("id"));
  // Other declarations
}

Or directly:

Code

wxMyPanel::wxMyPanel(wxWindow* parent, wxWindowID id): wxPanel(parent, id)
{
  //(*Initialize(wxMyPanel)

  // Other declarations
}

53

Development / Re: wxSmith : add option for Create function in inhereited cases

« Last post by ollydbg on January 25, 2026, 05:54:35 am »

Hi, I use some my own defined wxWidgets control from time to time. When I try to add this custom control in the wxSmith GUI designer, you can select the "Custom" control, and define the constructor yourself.

Is this the case I describe above?

54

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 January 25, 2026, 03:27:23 am »

I looked at some source code here:

\src\plugins\contrib\wxSmith\wxwidgets\properties\wxscolourproperty.cpp

I see some function get override, such as:

Code

    // This is based on the code of wxSystemColourProperty in advprops.h|cpp of wxPropertyGrid
    class wxsMyColourPropertyClass : public wxEnumProperty
    {
        WX_PG_DECLARE_PROPERTY_CLASS(wxsMyColourPropertyClass)
    public:

        wxsMyColourPropertyClass( const wxString& label = wxEmptyString,
                                const wxString& name = wxPG_LABEL,
                                const wxColourPropertyValue& value = wxColourPropertyValue(wxsCOLOUR_DEFAULT,*wxWHITE) );
        ~wxsMyColourPropertyClass();

        virtual void OnSetValue();
        virtual bool IntToValue( wxVariant& variant, int number, int argFlags = 0 ) const;

        /** Override in derived class to customize how colours are printed as strings.
        */
        virtual wxString ColourToString( const wxColour& col, int index, int argFlags = 0 ) const;

        /** Returns index of entry that triggers colour picker dialog
            (default is last).
        */
        virtual int GetCustomColourIndex() const;

        virtual wxString ValueToString( wxVariant& value, int argFlags = 0 ) const;
        virtual bool StringToValue( wxVariant& variant,
                                    const wxString& text,
                                    int argFlags = 0 ) const;

Do you mean that we need to add a special function overloading here?

See here:

https://docs.wxwidgets.org/3.3/classwx_p_g_property.html


I see VZ(wx developer) just close my issue, and he suggest that we need to override some functions myself.

Am I correct?



EDIT:

See this code in

https://github.com/wxWidgets/wxWidgets/blob/master/src/propgrid/advprops.cpp#L1102C1-L1182C2

Code

#if WXWIN_COMPATIBILITY_3_2
// By call to obsolete function we want to check if user-overriden function is still in use
wxString wxSystemColourProperty::ColourToStringWithCheck(const wxColour& col, int index,
                                                         wxPGPropValFormatFlags flags) const
{
    m_oldColourToStringCalled = false;
    wxString res = ColourToString(col, index, static_cast<int>(flags));
    if ( m_oldColourToStringCalled )
    {
        // 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 ColourToString with 'flags' argument as wxPGPropValFormatFlags", GetClassInfo()->GetClassName()));
    }
    return res;
}
#endif // WXWIN_COMPATIBILITY_3_2


wxString wxSystemColourProperty::ColourToString( const wxColour& col,
                                                 int index,
                                                 wxPGPropValFormatFlags flags ) const
{


    if ( index == wxNOT_FOUND )
    {


        if ( !!(flags & wxPGPropValFormatFlags::FullValue) || !!(m_flags & wxPGPropertyFlags_ColourHasAlpha) )
        {
            return wxString::Format(wxS("(%i,%i,%i,%i)"),
                                    (int)col.Red(),
                                    (int)col.Green(),
                                    (int)col.Blue(),
                                    (int)col.Alpha());
        }
        else
        {
            return wxString::Format(wxS("(%i,%i,%i)"),
                                    (int)col.Red(),
                                    (int)col.Green(),
                                    (int)col.Blue());
        }
    }
    else
    {
        return m_choices.GetLabel(index);
    }
}


wxString wxSystemColourProperty::ValueToString( wxVariant& value,
                                                wxPGPropValFormatFlags flags ) const
{
    wxColourPropertyValue val = GetVal(&value);


    int index;


    if ( !!(flags & wxPGPropValFormatFlags::ValueIsCurrent) )
    {
        // GetIndex() only works reliably if wxPGPropValFormatFlags::ValueIsCurrent flag is set,
        // but we should use it whenever possible.
        index = GetIndex();


        // If custom colour was selected, use invalid index, so that
        // ColourToString() will return properly formatted colour text.
        if ( index == GetCustomColourIndex() &&
             !(m_flags & wxPGPropertyFlags_HideCustomColour) )
            index = wxNOT_FOUND;
    }
    else
    {
        index = m_choices.Index(val.m_type);
    }


#if WXWIN_COMPATIBILITY_3_2
    // Special implementation with check if user-overriden obsolete function is still in use
    return ColourToStringWithCheck(val.m_colour, index, flags);
#else
    return ColourToString(val.m_colour, index, flags);
#endif // WXWIN_COMPATIBILITY_3_2 | !WXWIN_COMPATIBILITY_3_2
}

https://github.com/wxWidgets/wxWidgets/blob/8245e1073ae66fd246d2ec180160d2e20acf3644/interface/wx/propgrid/advprops.h#L92C1-L168C1

This is the header file.

55

Nightly builds / Re: The 06 December 2025 build (13761) is out.

« Last post by AndrewCot on January 24, 2026, 10:57:54 pm »

Whatever tool is used to create the compiler options checklist seems to fail when it encounters a mingw-w64 GCC compiler version that it does not "know", i.e.:
When the selected compiler is reverted to a compiler that the tool "knows" it does not go back to the checklist and stays with the blank tab.

As requested last year when you posted what looks like the same issue can you post instructions on how to re-create this and include the OS and CB version you are using.

56

Development / Re: wxSmith : add option for Create function in inhereited cases

« Last post by LR83 on January 24, 2026, 05:25:13 pm »

I try to add the option.
- Add m_Create property in wxsBaseProperties
- wxsItem::GetCreatePrefix, test the m_Create property. If false, I just add '//' before the Create function. So we can always see the parameters of the Create function (may be usefull).
Work for my project but I don't know if my solution is always good.
See the corrected files in the attachment.

57

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 January 24, 2026, 12:48:14 pm »

I see that the propgrid sample in the wx3.3.1 works fine. So, maybe it is still something wrong inside our C::B code base?

58

Nightly builds / Re: The 06 December 2025 build (13761) is out.

« Last post by ChosenName on January 24, 2026, 12:03:05 pm »

Whatever tool is used to create the compiler options checklist seems to fail when it encounters a mingw-w64 GCC compiler version that it does not "know", i.e.:



When the selected compiler is reverted to a compiler that the tool "knows" it does not go back to the checklist and stays with the blank tab.

59

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 January 24, 2026, 04:05:20 am »

I wrote an issue in the wxWidgets github

crash inside the GetValueAsString function of propgrid control in wx 3.3.1 under Windows 10 Issue #26108 wxWidgets/wxWidgets

60

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 January 24, 2026, 03:48:13 am »

Yes, I agree, I see the call stack is not from the wxSmith's source code.

The problem is that if I can't open a wxSmith file in C::B, and we can't fix such issue in the C::B side, I have to revert to use wx 3.2.x to build C::B. I have already switched to use wx 3.3.1 in my github action to build C::B.