Indirect Component Property Binding via RunScript - improve?

Working code: The following expression binding works to dynamically bind a dataset custom property of Component1 to dataset custom properties (“data”) of other components which set Component1.OtherComponentName to their own name when clicked in the runtime.

toDataSet(runScript("system.gui.getWindow('folder/window').getRootContainer().getComponent('" + {Root Container.Component1.OtherComponentName} +"').data"))

Code that does not work: Something like the following would be better as it will work regardless of parent window path/name, but it does not work as system.gui.getParentWindow() expects to have an event passed to it and there is no event to pass to it when used in an expression binding like this:

toDataSet(runScript("system.gui.getParentWindow().getRootContainer().getComponent('" + {Root Container.Component1.OtherComponentName} +"').data"))

Is there away to get the parent window for this purpose without hardcoding the name (‘folder/window’ in working code above)? Or is there a better way to do this?

1 Like

You could try adding a custom property to the rootContainer that updates itself when the window’s internalFrameActivated event is fired:

parentWindow = system.gui.getParentWindow(event)
parentWindow.rootContainer.winName =
toDataSet(runScript("system.gui.getWindow('" + {Root Container.winName} +"').getRootContainer().getComponent('" + {Root Container.Component1.OtherComponentName} +"').data"))

That is a great workaround for dealing with the window name.

Nick Mudge
Ignition Consultant

Thanks Adam! With “internalFrameActivated” as the filter, the property did not get set (perhaps a timing thing?) but “componentRunning” works. The code below also uses “path” instead of “name” to get folders preceding the window. This code in the root container property change event script works in clients:

if event.propertyName =="componentRunning":
	parentWindow = system.gui.getParentWindow(event)
	parentWindow.rootContainer.winName = parentWindow.path

However, it does not work in the designer, meaning functionality tied to this (lots in this use case) cannot be tested inside the designer. What would be required to get this script to work in the designer–even if only in preview mode?

Instead of using the rootContainer’s propertyChange event, try using the WINDOW’s internalFrameActivated.

That would do it; my mistake. Thanks Adam. This code in the window’s property change script works for clients (EDIT: this code does NOT work - see next post):

if event.propertyName =="internalFrameActivated":
	parentWindow = system.gui.getParentWindow(event)
	parentWindow.rootContainer.winName = parentWindow.path

Is there a way to get scripts like this to run in the designer–at least in preview mode? Or another way to get this property to set itself in the designer?

Oops, I posted too soon. The value was already set when I published this code, and it remained set… When I restarted the Vision client, the window script code in the previous post did NOT result in setting this value. Here’s a screenshot of what does NOT work:
[attachment=1]Message 2014.05.01 130748.bmp.jpg[/attachment]
Options that do work in client:
1 - The previously posted code in root container property change event script:

if event.propertyName =="componentRunning":
   parentWindow = system.gui.getParentWindow(event)
   parentWindow.rootContainer.winName = parentWindow.path

2 - This script on window:
[attachment=0]Message 2014.05.01 130850.bmp.jpg[/attachment]
Both of these options definitely work in the client. I’m still hoping there’s some way to make this happen in the designer as well. Any suggestions?

I know you want to be able to test things in the designer but I just want to suggest the idea of testing things in the client instead of the designer.

Personally most of my testing is done in the client, not in the designer. You can easily open a staging client and test there.

Nick Mudge
Ignition Consultant

I agree with Nick. Testing in the STAGING client is better than testing in the Designer.

Thanks Nick and Adam. The staging client works well where more than a single Vision license is available. In this case, it’s an on machine stand-alone single license HMI that will be duplicated on more stand-alone machines.

Maybe I’ll put in a feature request to include one staging client with each vision license, or–at minimum–to allow staging clients to run with trial mode reset on a system with a limited vision license.

Feature request posted here.

You can always install Ignition locally and run the two hour free trial. Just make a backup of your system and then restore to your local Ignition Gateway. Disable any transaction groups or anything else that may cause double database entries and you should be good.

With that said, I do agree that the Ignition license should include a developer’s license as well.