Focus Gained While Using Navigation Tabs

A few years back our company used buttons to navigate throughout the pages of our plant HMI before we started transitioning over to using tabs for navigation using the Tab Strip Customizer.

Unfortunately, we have seen quite an uptick in our accidental tag writes since using tab navigation feature due to the fact that the Button components appear to have a “focusGained/focusLost” event handler that takes the focus off last location of the HMI. The Tabs component does not appear to have this same functionality as a default so even though we navigate to another page altogether, we can still accidently write to a tag on a different page if we are still highlighted in the tag. Is there a way to add this type functionality to the tab navigation bar? or another focusGained/Lost functionality on the background of the HMI so when the container is clicked, it takes the focus off of the input text of a tag?

I’ve attached some screen snippets for reference.

Just to clarify -
Is what you're describing that you're on Window A, with focus in a text field, and then navigate to Window B, type some characters, and they're entering window A's text field? If that's the case, then it sounds like your navigation might not be set up correctly? The "typical" navigation strategy for Vision is to only ever have a single main window open at a time; the tab strip should swap out Window A -> Window B in such a way that Window A no longer exists, and thus cannot still have focus.

1 Like

PGriffith, to skip the latency that occurs when loading and swapping between pages, we have the pages layered on top of each other. So once the page is opened, it stays opened.

Vision's tab strip, if you allow it to open windows, only supports swapping. You MUST NOT allow multiple main windows. Use window caching to minimize the window swap latencies.

If you script window changes, you can do as you please. But then such scripts can control focus, too.

1 Like

The simplest workaround would probably be to switch the tab strips to 'Disabled' and use a script to both "swap" windows & programmatically request focus:

print event.propertyName, event.newValue

if event.propertyName == "selectedTab":

Kapture 2022-10-04 at 10.51.34

1 Like

Is there a similar script that can be written on the root container Event Handlers -> mouseClicked -> Script Editor to take focus away from a selected tag? This similar functionality would also help.

You might want to read through the relevant doc page.

By requesting focus on X you automatically take away focus from Y .

I don't think you can focus on multiple things at once. But I could be wrong.


Andrews, I probably do not have a clear understanding of how the focusGained/focusLost works or where for that matter. But I would like the focus to be taken away from the tag when I click any where else on the the background (or container in this instance) to prevent accidental tag writes. So the container should request the focus when it is clicked and the tag should lose focus. I hope this makes sense.

You keep saying 'tag', but without a clear picture of your actual components I have no idea what specific component this is.

If it's a text field, where you're entering tag values, perhaps you just want to set 'Commit On Focus Loss' to false?

1 Like

Note that "focus" is short for "keyboard focus". If input components exist on a window, java Swing will keep focus in something. Not a container.


Sorry PGriffith for the confusion and late reply, these are essentially components with Text inputs in them. I've confirmed that we have the Commit On Focus Loss set to False and any change does require the enter button to be pressed. I've been told that there are some Ignition applications setup up similarly, where the focus/curser is inside of a text field, but when you click on the background of the application (container), it takes the focus out of the text input field.

PGriffith, I appreciate the help. I think this may be the best solution so far. I am going to mess around with this and see if we can get this to work on our applications.

So, I get what you are saying. Let me try to clarify for you.

A tag does not have focus.

A input component does have focus.

A tag can be linked to an input component (not required).

A container can't assume "focus" on its own.

You want to loose focus on the input.

I just played around with it and can see what you are talking about.

I have two ways to deal with this.

Preferred way: If this happens between windows you may not be closing them. That is a simple setting. Just set the window to close when focus is off of it. (can't have focus on a closed window)

un-preferred way: I have a nitty gritty unpretty dirty workaround, and I'm sure there is a better way.

Create a input component, maybe put it in the nav so it has easy access all the time. Hide it with a box on top so it's out of site (unseen and pretty). Then for each input component > go to the scripting section for it. In the focusLost script section, script it to gain focus to that hidden input component.

Then ideally each time your input component (linked to tag) looses focus, you will gain focus on that hidden input component in your nav, which is a dud input component linked to nothing and does nothing.

That should work perfectly for you, I wish I knew of a cleaner way to do it though. Hopefully that made sense to you.

Andrews, thank you. We currently keep the windows up, layered on top of each other, which only amplifies the issue because now we can accidently write to a text input on a window that is opened in the background, the first window opened appears to gain and keep the focus. Swapping windows and caching the data has been brought up as a potential fix as well, the reason we layered the windows to begin with is to limit latency while operating during startups.

We used to use button components as a navigation tool prior to the navigation tabs, which worked well because the button components actually have this gain focus functionality, so after clicking on one of the navigation buttons, if we used the tab key it would toggle between the button components within that container, taking focus away from the text input on the window.

Example of what is happening; we have remote operators taking manual rounds in an excel spreadsheet, swapping between multiple ignition applications and an excel application. In the middle of these manual rounds, they have to navigating throughout our ignition plants. They sometimes hit the tab key and input values thinking they are still in the excel spreadsheet, when in reality they are still on the ignition HMI. Even though they have not clicked inside of a specific text input, by using the tab key, they had essentially tabbed into this text input by accident. And since we overlap windows, the scary part is the focus could essentially be anywhere on the HMI. We run 24 hour ops and have these clients open 24/7, being run by multiple operators. If possible, another part of the solution could be to keep the tab key from shifting focus from one text input to the next.

  • This is not so much a problem locally because their computer are designated specifically for operating the plant. This has, however, started to become more of a problem for remote operations since we have been swapping all of our plants over to ignition recently and use the computers mostly for monitoring plants among other things. This problem is probably going to take some process changes as well as integration changes, just trying to get some advice from some seasoned professionals.

Yeah I get all that.

But it still remains, close the windows or have another component which can gain focus for you and does nothing.

You could remap the tab key, but I don't think that really fixes your issue. You will still stay focused on something.

PGriffith, late response but I wanted to let you know that we were able to use this script /script similar to this one to fix our issue. Thank you for your help!

1 Like