Disable static text of wxStaticBoxSizer Topic is solved

[Widgets]

This issue has bothered me for some time and it evidently has done the same for others - see these 2 threads:
1) viewtopic.php?t=35347

2) viewtopic.php?f=23&t=43641

The problem I want to resolve is to actually grey out the label of the wxStaticBoxSizer() as shown in image 2 posted for thread 2, both of which I have attached.

The work-around discussed in thread 1: enclose the static sizer in a wxPanel does not grey out the static box label for any wxStaticBoxSizer either, though it does disable the rest of the contents - at least the ones I have tried.
The native code which is part of thread 2 does indeed grey out the label, but it does it by fiddling with the manifest

[PB]

Looking at the buttons in the screnshot, your application seems to be missing a common controls manifest - if so, what is different from what I wrote in the last post of the second thread you linked, i.e., without a manifest the static box does not show disabled? What manifest "fiddling" do you mean? A Common controls manifest should be used in MSW applications since 2001 (introduction of Windows XP)? BTW, an application should have a compatibility manfiest and DPI awareness stated as well.

Which wxWidgets version do you use - there were some changes in past year or so like this.

[Widgets]

Looking at the buttons in the screnshot, your application seems to be missing a common controls manifest - if so, what is different from what I wrote in the last post of the second thread you linked, i.e., without a manifest the static box does not show disabled? What manifest "fiddling" do you mean?
A Common controls manifest should be used in MSW applications since 2001 (introduction of Windows XP)? BTW, an application should have a compatibility manfiest and DPI awareness stated as well.

Looks like this will be my introduction to 'manifests'
What you wrote works in the sample you attached (compiled under MSVC 2017 & using wxWidgets 3.1.1), but ....
In all my work using wxWidgets to build apps for Windows, this is the first time I apparently need to consider the 'manifest'.
For more years than I care to count, I have used MSVC Express or public edition from about MSVC 2008 to the current MSVC 2017, from WinXP through Win10. Not once did I need to worry about or modify whatever manifest MSVC attached to the executables it generated.
Neither have I even contemplated worrying about themes - perhaps I should or should have. But since most of my development was for my own needs and environment, I never saw the need to worry about either themes or manifests, because the default behavior always seemed to be what I had expected based on what I saw in other Windows applications from a variety of sources and developers - except for wxStaticBoxSizer. This 'problem' was something I had been 'leaving for another day' for some time, until in my current app, I decided to tackle it.

Which wxWidgets version do you use -

3.1.1 with MSVC 2017 - mostly using static linked wxWidgets libraries

there were some changes in past year or so like this.

If I read the github comments correctly, these changes apply to wxWidgets 3.1.2, so perhaps I should upgrade, though I see that this version was release just a few weeks back.
Do you think these changes address the issue I am trying to resolve?
If I get a chance, I will try to upgrade and see what, if any difference the change will have.

[PB]

Regarding the manifests - there are basically two:
Common controls manifest, where your application states that is uses common controls v6 introduced with Windows XP and therefore will be themed according to the theme Windows is using. In other words, this is quite noticeable with push buttons whose appearance seems to change significantly with every major windows version - those in your screenshot look unthemed, i.e., just like Windows 95 ones. This manifest is added automatically by MSVC 2005 and newer, see also WXWIN/docs/msw/windowsxp.txt. BTW, I have just downloaded your? wxSR and it does have a theme manifest.

Application compatibility manifest, where the most important settings from GUI point of view may be those related to non-standard DPI. See here for more https://docs.microsoft.com/en-us/window ... -manifests

Regarding your issue
As I wrote in the other thread, in a themed application on modern Windows, for some reason a static box looks the same whether it is enabled or not. Since one does want an application to be themed, it seems that the only option would be working around this.

wxStaticBox allows to use a custom control as its label and you can enable/disable this one. The static box border will still look the same but perhaps it would be good enough (although it looks quite ugly)?

statbox.png (7.24 KiB) Viewed 2307 times

The above was produced with this

Code: Select all

#include <wx/wx.h>

class MyDialog : public wxDialog
{
public:
    MyDialog() : wxDialog(NULL, wxID_ANY, "Test", wxDefaultPosition, wxSize(500, 400))
    {                                     
        wxBoxSizer* mainSizer = new wxBoxSizer(wxVERTICAL);

        wxStaticBoxSizer* sbSizer1 = new wxStaticBoxSizer(wxVERTICAL, this, "Enabled wxStaticBoxSizer");
        sbSizer1->Add(new wxButton(sbSizer1->GetStaticBox(), wxID_ANY, "Button"));

        wxStaticBoxSizer* sbSizer2 = new wxStaticBoxSizer(wxVERTICAL, this, "Disabled wxStaticBoxSizer");
        sbSizer2->Add(new wxButton(sbSizer2->GetStaticBox(), wxID_ANY, "Button"));
        sbSizer2->GetStaticBox()->Disable();

        wxStaticText* label = new wxStaticText(this, wxID_ANY, "Disabled wxStaticBoxSizer with disabled wxStaticText label");
        wxStaticBox* staticBox = new wxStaticBox(this, wxID_ANY, label);
        wxStaticBoxSizer* sbSizer3 = new wxStaticBoxSizer(staticBox, wxVERTICAL);
        sbSizer3->Add(new wxButton(sbSizer3->GetStaticBox(), wxID_ANY, "Button"));
        sbSizer3->GetStaticBox()->Disable();
        label->Disable();
        
        wxCheckBox* cbLabel = new wxCheckBox(this, wxID_ANY, "Click to enable/disable controls inside");
        cbLabel->Bind(wxEVT_CHECKBOX, &MyDialog::OnEnableDisableSizer, this);
        staticBox = new wxStaticBox(this, wxID_ANY, cbLabel );
        m_sbSizer4 = new wxStaticBoxSizer(staticBox, wxVERTICAL);
        m_sbSizer4->Add(new wxButton(m_sbSizer4->GetStaticBox(), wxID_ANY, "Button"));        
        m_sbSizer4Enabled = true;

        mainSizer->Add(sbSizer1, wxSizerFlags().Expand().DoubleBorder());
        mainSizer->Add(sbSizer2, wxSizerFlags().Expand().DoubleBorder());                    
        mainSizer->Add(sbSizer3, wxSizerFlags().Expand().DoubleBorder());                    
        mainSizer->Add(m_sbSizer4, wxSizerFlags().Expand().DoubleBorder());                    
        SetSizer(mainSizer);         
    }       
private:
    wxStaticBoxSizer* m_sbSizer4;
    bool m_sbSizer4Enabled;

    void OnEnableDisableSizer(wxCommandEvent&)
    {
        m_sbSizer4Enabled = !m_sbSizer4Enabled;
        m_sbSizer4->GetStaticBox()->Enable(m_sbSizer4Enabled);        
    }
};

class MyApp : public wxApp
{
public:   
    bool OnInit()
    {
        MyDialog().ShowModal();
        return false;
    }
}; wxIMPLEMENT_APP(MyApp);

[Widgets]

Regarding the manifests - there are basically two:
Common controls manifest, where your application states that is uses common controls v6 introduced with Windows XP and therefore will be themed according to the theme Windows is using. .... This manifest is added automatically by MSVC 2005 and newer, see also WXWIN/docs/msw/windowsxp.txt.

I very much appreciate your comments regarding the manifests. As I said, til now, they have been below my radar because I never found any reason to worry about them.

BTW, I have just downloaded your? wxSR and it does have a theme manifest.

That was one of my very early efforts at doing something useful with wxWidgets and back then 'manifest' was only a word for me, more or less exclusively used in shipping.
Any manifest which is part of that application ended up there unbeknownst to me and without any effort or intent in my part. As well, that app dates pretty well back to about the XP days

Application compatibility manifest, where the most important settings from GUI point of view may be those related to non-standard DPI. See here for more https://docs.microsoft.com/en-us/window ... -manifests

Something I will want to look into, if only for my education.

Regarding your issue
As I wrote in the other thread, in a themed application on modern Windows, for some reason a static box looks the same whether it is enabled or not. Since one does want an application to be themed, it seems that the only option would be working around this.

wxStaticBox allows to use a custom control as its label and you can enable/disable this one. The static box border will still look the same but perhaps it would be good enough (although it looks quite ugly)?

In reflecting on & researching this issue some more over the past few days, I have more or less decided to live with the current behavior, at least until I can come up with a workable solution.
Perhaps I will have to look at your work-around using the manifests, perhaps...
One of the things I had not considered until recently, was that part of the problem is that I have been using wxCrafter to make up the code for my GUIs. This in itself has limited my choices only to the options available/implemented in the utility, without more manual intervention at a later stage.

For instance I had never really given much thought to using anything but a static text string as the label.

In my efforts to make the GUI look as I expected, I had pretty well drilled down to get a pointer to the static box and was looking for a way to get a pointer to the actual label. All this eventually led me to read the HTML documentation, which sheds some light on the underlying issues, and one of the examples you give - the last box with the checkbox label illustrates the apparent reasoning which seems to have led to the current behavior.
The portion of the HTML documentation, which initially had me very puzzled, says,
https://docs.wxwidgets.org/3.1/classwx_ ... 0875bec707

wxStaticBox overrides wxWindow::Enable() in order to avoid disabling the control used as a label, if this box is using one. This is done in order to allow using a wxCheckBox, ...

IOW, the need to handle a check box label in a usable way, resulted in code which makes it impossible to disable any text string label - or apparently any other suitable candidate
And therein, IMO, lies both the cause and an eventual solution to this 'issue'.
If the current code is necessary to handle a check box in a workable way, then it should ONLY apply to the case where the label is a checkbox.

I have tried to trace through the code, but have not yet been able to pinpoint the exact spot where such a test could be implemented.
Then again, the issue is not a show stopper for me, so I don't see that I will be able to invest a great deal of time or effort.

[PB]

I am sorry but I have to admit I did not understand your reply much

Perhaps I will have to look at your work-around using the manifests, perhaps...

There is no workaround using manifests, my simple workaround uses a disabled wxStaticText - see the third box in my screenshot and code.

IOW, the need to handle a check box label in a usable way, resulted in code which makes it impossible to disable any text string label - or apparently any other suitable candidate
And therein, IMO, lies both the cause and an eventual solution to this 'issue'.
If the current code is necessary to handle a check box in a workable way, then it should ONLY apply to the case where the label is a checkbox.

As you can see in the screenshot and code in my post, it is very possible as well as easy to make a visually disabled text label for a static box. And as I wrote before, the label not being drawn as disabled for a staticbox is native Windows behaviour. I hope I made that clear in my previous post. :(

The checkbox label in my example just showed how one can use the label checkbox to disable/enable the controls inside the static box, instead of using a separate control as you had it in your screenshots.

[Widgets]

There is no workaround using manifests, my simple workaround uses a disabled wxStaticText - see the third box in my screenshot and code.

Understood. Still, as I see it, it is a choice of 'work-arounds' then.
My hope was to understand and perhaps find a way to handle the, at least to me, quite unexpected results.

As you can see in the screenshot and code in my post, it is very possible as well as easy to make a visually disabled text label for a static box.
And as I wrote before, the label not being drawn as disabled for a staticbox is native Windows behaviour. I hope I made that clear in my previous post.

IIRC, this is the first time you refer to what I see as 'native Windows behaviour". Not being particularly familiar with Windows development without wxWidgets, I have not been able to find anything else from MS regarding this.
As well, the wxWidgets documentation I quoted, more or less led me to believe that the observed results were due to wxWidgets design decisions to handle this specific check box example, rather than MS defaults.

The checkbox label in my example just showed how one can use the label checkbox to disable/enable the controls inside the static box, instead of using a separate control as you had it in your screenshots.

Agreed. But that is not really the problem I face, though I think I could reconfigure things to use check boxes. In the current configuration which prompted the post on this subject, I have a 2-button radio box and I need to enable/disable several wxStaticBoxSizers, depending on the status of the radio button box.
I used the check box example image, because it illustrated the problem of disabling the label on a wxStaticBoxSizer, given nothing but a pointer to a parent or grandparent of the sizers.
As yet, I have not found a way to work backwards from such a pointer to disable the label, if necessary.
This scenario is rather common in the way I have structured the options dialogs in my app(s) and it would be much simpler tho find a way to handle this without abandoning my GUI builder and instead manually building my dialogs just to work around this issue.
In fact it is this dilemma which made me ignore the issue until now and to leave things as they are is, for me, the simplest work-around

[PB]

IIRC, this is the first time you refer to what I see as 'native Windows behaviour". Not being particularly familiar with Windows development without wxWidgets, I have not been able to find anything else from MS regarding this.

Sorry, I thought it was clear from the last post in the second thread you linked, the code you referenced as "native"; there is also a link to Google search results for the issue.

This scenario is rather common in the way I have structured the options dialogs in my app(s) and it would be much simpler tho find a way to handle this without abandoning my GUI builder and instead manually building my dialogs just to work around this issue.

Ah, I did not notice that you needed to solve the issue using a GUI builder, so my point was to show that having a visually disabled label for wxStaticBoxSizer was easily doable. I do understand that it can be rather inconvenient to not be able to use the usual workflow. The solution I used would not be even possible with e.g. wxFormBuilder which seems to lack wxStaticBox, it only has wxStaticBox sizer...

[Widgets]

Sorry, I thought it was clear from the last post in the second thread you linked, the code you referenced as "native"; there is also a link to Google search results for the issue.

At the start, I just found and used the image - for convenience; meanwhile, as a result of this discussion, I have also followed my own and the Google search you had recommended in that post and have learned a lot

Ah, I did not notice that you needed to solve the issue using a GUI builder, so my point was to show that having a visually disabled label for wxStaticBoxSizer was easily doable. I do understand that it can be rather inconvenient to not be able to use the usual workflow. The solution I used would not be even possible with e.g. wxFormBuilder which seems to lack wxStaticBox, it only has wxStaticBox sizer...

Well, I don't really have to ....(and neither does wxCrafter have wxStaticBox - yet) but, for now, I'll mark this thread as resolved and start learning more about themes, manifests etc
Maybe there is another work-around out there