How to get the component associated with the Active Tab (Z-Index vs. Tab Index)

Ignition
, ,
1

I am writing a script to identify and interact with the component currently visible inside a Tab Container based on its currentTabIndex.

I’ve encountered a challenge: container.getChildren() returns components in the order they appear in the Z-index/Component Tree, which does not always match the order defined in the props.tabs array. For example, my 3rd tab in the UI might be the 1st child in the tree, causing getChildren()[active_index] to return the wrong component.

My Goal:
Is there a reliable way to pinpoint the exact component object currently active in the view without relying on the Z-index order?

container = self.getSibling("TabContainer")
active_index = container.props.currentTabIndex

# This is fragile because it follows the Tree order, not the Tab order:
all_children = container.getChildren()
active_comp = all_children[active_index] 

system.perspective.print("Active Name: " + active_comp.name)

What I've tried:
I am currently trying to match the name property from the props.tabs array against the names in getChildren(), but I was wondering if there is a more direct "Perspective-native" way to access the active tab's child object directly.

Any advice or best practices would be appreciated!

2

What is the end goal here? What are you intending to do on the associated child component(s)? The fact that you say interact makes me think you are trying to execute a button or similar, but i could be misinterpreting it.

Elaborate, what do you plan on doing with this component once you've gotten the reference to it?

3

I will basically Identify the

  • type of the component

if it is a table then export its data else ignore

I don’t want to manually pass the component name or types, need something dynamic that still works when Parent container inherit more children.

4

Have the tables' data as view private custom properties. On request to export, grab the selected tab index and have a list of property names that are associated with that tab. Grab only the data from those properties and export.

You should follow this pattern for control entries (start and end timestamps, record filters, etc) as well, as it makes them resilient to the driving components moving to different containers.

The other option would be to have a generic message handler on the tables that just grabs data from props.data and then dumps it into a file. You would not be able to have the tab container set to run unselected tabs in the background.

1 Like
5

I like the second option, I can also add tabIndex ID in the message handler of the table and can broadcast the message with selected tab index, and target table will automatically export it's data.

6

Ah yes, I forgot about the payload, that would alleviate the issue with the unselected tabs running in the background.

7

Exactly. It will be more cleaner than the solution I was trying to build.