I have a Tab container with two subviews (Tab1 and Tab2), I have created a button "increase" which increases a custom variable each time it is clicked.
If I increase the counter to 3 in "Tab1" and move to the other tab view "Tab2" and return to "Tab1" the counter is reset to 1.
A tab container should behave imho just like stacked papers on my desk: if I jot down some numbers on a paper and then switch to another paper and then return to the former I don't expect the paper to become clean again!
Of course this is just a simple example however consider the tab component is often used to simplify very complex user interfaces which cannot be dealt within a single view: having each tab reset itself at the change of the tab is a great headache during development.
We think there are also more subtle bugs of the tab component apart from resetting itself (which could itself be dealt with session bindings, or bidirectional parameters but would make the creation of a complex tab view a nightmare for developers), we have examples of the same tab view loading correctly sometimes and some other times not loading correctly as if the custom bindings didn't fire consistently each time.
If you could please address this issue because it is really annoying.
PS: will ignition project attachments be allowed in the future on this forum? I currently have to use third party upload services to share ignition example files.
Hi, as I said, attached is a very simple example which could be dealt with session bindings or bidirectional parameters but would make the creation of a complex tab view a nightmare for developers.
Apart from that I would see the following happening:
session would be polluted with variables which belong to embedded views of a tab container of a view, we have hundreds of views it would be an architectural disaster imho to put them in the session.
session itself has its weird behaviours (it caches user values for some time once a page has opened and persists them even after user logout only to invalidate them after some time).
moving logic which belongs to a sub view to the parent tab container just so that the tab container can retain the value once the page resets itself on tab change is a nightmare, it would make us probably opt to create two different pages which is not what we want.
Consider storing critical state in a viewVarMap() or pageVarMap(). (Probably want the pagVarMap() for this case.) From my Integration Toolkit add-on module.
(These were inspired by a discussion of maintaining page or view state through complex workflows without polluting session variables. And without worrying about long-term memory leaks. And holding the jythonic nature of variables, instead of suffering JSONification everywhere.)
thank you for your input, I would first try avoiding third party modules for such low level things if possible.
The problem of reloading the tab each time the user switches tab is a problem itself anyway even if variables can be somehow stored inside the tab. Imagine re-executing complex queries each time a user switches tab (almost all complex views involve some kind of query on the DB).
We also have several problems with the order of execution of custom variables but I'll open a separate thread for that problem.
Hi Jordan, according to which post? anyway if the views in tab container stayed running the embedded views of each tab should load once when tab is opened and then stay the same. I suspect some kind of reloading is happening when changing between tabs.
I linked to the specific post saying that, in v8.1.5, views should stay running if you switch to another tab. I would say that is the behavior you are wanting. Instead, it reloads whatever is in the embedded view, effectively 'resetting' to the original.
There seems to be some confusion here. In 8.1.5 we added a boolean property which exists only under special circumstances, and you must add it yourself. By default, Tabs do not continue running if they are not the active tab. To have a Tab continue to exist - and therefore maintin state - you must modify the tab entry to be an object and supply the runWhileHidden property.
Steps:
Identify the index of the tab which you would like to have its state maintained as you switch between other tabs.
Right-click that index and select "Change to", and the "Object". There will be warnings in the Property Editor until we complete our process.
Click "Add Object Member" within your new object, and select "Value".
Modify the key of the new prop to be text, and supply the text you would like displayed for the tab.
Hover over your object index, then click the + displayed to the right.
Select "Value".
Set the key of this new prop to be runWhileHidden, then set the value to true.
There should now be no warnings, and your props should look like this:
With this setup in place, I was able to increment your counter and navigate between tabs, then go back to the first tab and the count remained incremented.
