My issue is this....looking at an old HMI (Delphi 5 w/Pascal - what fun) they set a tag value based on what forms are open/visible by the operator. So in Ignition (vision) I have (2) pages with (5) tabs total. I created a mouse click script on each of those (2) tab strips that will manipulate the tag vale 1,2,3,4,5 etc.
That appears to fix #2 in limited testing. But if I remove the original mouse click script - the property change script does not update the tag value I wish when cycling through the tabs. (The tab strip is set to not navigate, and the .selectedTab property is used to set visibility on each of the (3) containers this tab strip is supposed to control).
To duplicate what I perceive the original HMI does.
Specifically in this case...
Write an integer to a PLC tag
0 if no operator has a linearizer page open/visible
1 if Bias RF linearizer open
2 if Antenna RF linearizer open
3 if Top magnet linearizer open
4 if Middlle magnet linearizer open
5 if Bottom magnet linearizer open
Not sure I know enough to answer your question they way you may prefer.
Ignition vision was sold to replace a WindowsNT based HMI. Along with a PLC CPUI upgrade (OMRON FINS driver in Ignition/Gateway which is working and I have the new CPU communicating)
I realize I may be going about this completely wrong. But ultimately the tag will need to write to the PLC.
So, I should broaden my approach to consider vision client scripting
Yes, that was made clear in the one Inductive university video I found. And I believe I followed the guidance therein so far as I used if statements.
# Check visibility
if event.source.getComponent('Top Container').visible:
value =  # Set Linearizer Mode Value
system.tag.writeBlocking(writepath, value) # Write Linearizer Mode Value
No, if the value must be written to a PLC, then a client tag is not the way to go.
No, you need to check for what property has changed, like @MMaynard did in his snipper above.
if event.propertyName == 'selectedTab':
The reason for this is that the property change event will trigger for ANY property that changes.
If you change the component's name, its name property changes, and it triggers the script. That's not what you usually want.
So, we filter with a line like the one above.
So in the end. @MMaynard 's property change script was put there.
Later, a colleague I reached out to, pointed out the window script option - which was hiding in (my admittedly myopic) plain sight. So I added scripting on the Window
internalFrameActivated - which took care of No.2
internalFrameDeactivated - which took care of No.1
No hair left. But, your and @pturmel 's point are taken.
Who would have thought that replacing a 23 year old HMI solution would have issues beyond just getting the data to/from the controller?
I am impressed that Omron's Cx programmer easily migrated the code from an ISA slot based controller to a new rack based CPU.