ReadOnly property

[itg-assistant]

Alex Prinias asked 2017-02-03 17:25:43 UTC

Hi guys,

Back in Nov-Dec 2016, you had added the ReadOnly property to ComboBox, which makes the reading of the control much easier compared to the grayed-out appearance of setting Enabled = false. The ReadOnly property is also there for TextBox. Is there the possibility of having this property for the Control base class?  I suppose it would be a combination of the Enable = false functionality in C# with the Enable = true appearance in the Theme... But of course I might be wrong! :)

Best regards,
Alex

[itg-assistant]

Luca answered 2017-02-06 17:23:18 UTC

Hi Alex,

Enabled and ReadOnly are treated differently. Enabled works for any control while ReadOnly is for editable controls and each editable control can be different (i.e. DataGrid or TextBox). There are base common classes when they share the base. In other words, ReadOnly in Control wouldn't work.

You can read the property without having to cast using a dynamic object:

dynamic control = this.textBox1;

bool readOnly = control.ReadOnly;

Works regardless of the class. You get a binding error if the ReadOnly property is not found.

HTH

Best,

Luca

[itg-assistant]

Alex Prinias answered 2017-02-06 17:33:01 UTC

Hi Luca,

Thanks for your answer. My "problem" is that I would like to show a form with various controls on it (textbox, datetimepicker, combobox, checkbox, groupbox, ...) without allowing the user to do any changes. This is achieved with each control's .Enabled = false, but the disabled controls are difficult to read as they are grayed out. That's why I would like to have them all as ReadOnly, which, for TextBox and ComboBox at least, does not gray them out but effectively disables them.

Best,
Alex

[itg-assistant]

Luca answered 2017-02-07 14:18:08 UTC

Got it. The Enabled property is inherited and allows you to enable/disable a container. The ReadOnly is specific. Some of the options could be to:

a) Modify the theme and change the disabled state, now it uses opacity to disable the entire control including child widgets;

b) Add a ReadOnly property to your containers (or add an extension method) and iterate the children of a container using a dynamic cast in a try/catch or using TypeDescriptor to get the "ReadyOnly" property.

HTH

Best,

Luca

[itg-assistant]

Alex Prinias answered 2017-02-07 17:49:59 UTC

Hi Luca,

I must be missing something basic here... Let's talk specifically about CheckBox, which does not have the ReadOnly property.

Option 1, if I go into ThemeBuilder, go to CheckBox and  make the Disabled state look like the Default state (change the opacity), this would mean that all my checkboxes throughout my application will look as enabled. However, I want to have this only in a specific form, not for all checkboxes.

Option 2, if I add a ReadOnly property to the GroupBox containing a CheckBox and a TextBox. Then, iterate over controls in my container (the GroupBox) and check for ReadOnly. It is present for the TextBox and the TextBox is indeed set to ReadOnly = true, but it is not present for the CheckBox and nothing changes. What do I achieve this way? The CheckBox is still editable.

Best,
Alex

[itg-assistant]

Tung Ngo answered 2017-02-07 18:26:48 UTC

Hi Luca,

Do you mean in option 1 is change the theme so the disable checkbox looks better (more contrast)?

And we just use Enable = True/False as now?

[itg-assistant]

Luca answered 2017-02-07 18:36:41 UTC

Hi Alex,

Got it. Another option is to create a new key for disabled but not grayed controls. You can create something like "readonly-checkbox", "readonly-textbox", ... inherit from the respective keys and now use the Enabled property. Assign the key to the control's AppearanceKey property. Something like this, in a mixin:

"appearances": {

"readonly-checkbox": {

"inherit":"checkbox",

"states": {

"disabled": {

"styles": {

// put styles for the disabled state.

},

"properties": {

// put styles for the disabled state.

}

}

}

}

}

I haven't tried this, and you may need to tweak it a bit.

Best,

Luca

[itg-assistant]

Luca answered 2017-02-07 18:37:30 UTC

Yes, see also new answer with an appearance that can be applied to specific controls.

[itg-assistant]

Alex Prinias answered 2017-02-08 12:42:35 UTC

Hi Luca,

That's it, your AppearenceKey method did the trick! So I added in my mixing the "readonly-checkbox", "readonly-textbox" etc, and a ReadOnly property to my control container, which, when set to true loops over the controls and makes their Enabled = false and sets the appropriate AppearenceKey for each control type. Very nice method, and once more, respect for the flexibility and clarity of Wisej.

During this exercise a few questions came up.

• What is the difference of "styles" and "properties" in an "appearance"? I.e. why is "opacity" a property and not a style?

• There are several theme "states" for each control: default, disabled, hovered etc. What really "links" this appearance state with the actual control state, i.e. the "disabled" theme state with the .Enabled = false status?

• Continuing from 2, could I alternatively define a "readonly" theme state and bind it with a control state?

And two features I saw:

• I was trying to disable/hide a tabpage of a tabcontrol, but both .Enabled = false and .Visible = false have no effect. Accidentally I found out there is a .Hidden property which indeed works. a. Is there a special reason why the Visible is not used and Hidden is preferred? b. It would be useful to have the disabled state also, i.e the tab visible but inactive - actually, now I think about it, this could be achieved with cancelling the selecting tab event.

• When disabling a control which has a Tool button, the Tool button remains enabled. If this is intentional, no problem, just reporting it in case it's not.

Thanks,
Alex

[itg-assistant]

Luca answered 2017-02-08 16:07:16 UTC

Hi Alex,

See answers below:

• Styles are converted to css classes using predefined "decorator" classes in qooxdoo and wisej. https://docs.wisej.com/theme-builder/theme-elements/styles The values in the styles become css properties in css classes built using a combination of appearance key and states. Properties instead map directly to properties in each widget and are unlimited - a widget can define any property as themeable and you can change (override) the value of a property programmatically. For example, we have backgroundColor as a style and as a property.

• States are arbitrary names defined by each widget. Some are common, like "disabled", others may be used only by a specific widget. You can add any state to widget using "this.addState('readonly')" or "this.removeState('readonly')". As soon as addState or removeState are called, the widget is scheduled for a UI update and will automatically update its rendering based on the values coming from the theme.

• TabPage.Visible returns whether the page visible (selected, or active). That's why we added Hidden. The Enabled property on the TabPage works as it disables the content of the TabPage but it doesn't change the style of the header (button) and lets you click (select) the page, otherwise the users wouldn't know what is disabled. You can prevent a tab from being selected using the events on the TabControl.

• The tool buttons don't inherit the Enabled property - I may have a disabled TextBox and an enabled tool button that allows the user to do something that enables the textbox, or similar scenarios.

HTH

Best,

Luca