Hi,
I read the changelog that I can disable a tab in the tab container. I'm complete new to ignition and I can't figure out where I do it?
From the manual: A boolean disabled property can be added to an element that's set to an object data type. This setting determines if a tab can be selected. If the tab is already active when it becomes disabled, users will not be prevented from leaving the tab, but they will not be able to get back to it. The content of the tab is not affected by the enabled/disabled state of the tab.
link to tab container: Perspective - Tab Container - Ignition User Manual 8.1 - Ignition Documentation
The props.tabs property is defaulted to array, so just change it to an object and add at least 2 keys (text and disabled).
example:
For clarity: you should right-click the 0th entry within tabs and select "Change to object". This new object should receive the new keys text and disabled.
1 Like
Thanks!
I changed to object but didn't get the text and disable. I found out how to add the myself.
It's hard because there aren't any "option" when adding in this case "value". So you don't know what you can choose from on a simple way
The manual does contain this information. See my link above.
1 Like
roughly translates to "this object needs to have you add the following keys yourself".
It would probably make sense for "Change to object" to insert the key that is implied when not an object. (Everywhere applicable.) And if already populated, to move the current value to that key. The component knows--there just needs to be some plumbing for the designer UI to know.
In this instance, neither text nor disabled is a required key; perhaps the user intends to make this tab render a View. When objects have required keys, we do add them -- like when adding instances to Flex repeaters.
I think the implied key when a component accepts a list should be treated specially, even if not actually required.
I've thought some more on this--reasoning through the "why" behind my gut reaction. The core of the issue, to me, is that "Change to object" shouldn't break a working view/component configuration. Placing the current list item value in the new object's corresponding key seems to me an intuitive transformation. And reversible--the infra to support such throughout the designer would also support a "Change FROM object" operation when that one key is the only one present.
1 Like