Ignition Tab Container losing custom variable when changing tab

I have the following SSCCE (Simple Self Contained Code Example) of an undesired behaviour in the Tab container component of ignition:

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.

I think the request at [IGN-2207] Is there a way to stop/intercept a Tab Container tab change? is somehow related but didn't want to pollute it with my request.

Thank you

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.

Your SSCCE is missing your embedded views.

That said, I suspect your custom property is in the embedded view. Consider puting it in either the Tab container or a session property.

I have updated it with the missing views

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.

Based on this post, I see what you're saying now. Let's ping @cmallonee and see if he can shed any light for us.

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.)

1 Like

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.

I opened a separate thread because this topic is more specific (or so I hope). Feel free to edit it if it's not clear enough.

According to the post, views in tabs are supposed to stay running. I just don't know if that extends down to embedded views within the tabs.

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.

EDIT: TL/DR: Yes, I agree. :wink:

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.

thanks I see now, I'll try the nightly 8.1.5 and keep you updated whether it solves this problem. Currently 8.1.33 is experiencing the problem.

I wouldn't downgrade, let's see if this is a regression.

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.


  1. Identify the index of the tab which you would like to have its state maintained as you switch between other tabs.
  2. Right-click that index and select "Change to", and the "Object". There will be warnings in the Property Editor until we complete our process.
  3. Click "Add Object Member" within your new object, and select "Value".
  4. Modify the key of the new prop to be text, and supply the text you would like displayed for the tab.
  5. Hover over your object index, then click the + displayed to the right.
  6. Select "Value".
  7. 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:
Screenshot 2023-12-19 at 8.27.29 AM

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.


Thank you, this feature is super useful, it solved several problems we had with some views due to the default behaviour of the tab component.