# Vision Scripting - What am I missing here? **URL:** \ **Category:** Ignition\ **Tags:** vision\ **Created:** [May 2, 2023, 10:50am UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137 "2023-05-02T10:50:45Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![S1ack](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/s1ack/32/22451_2.png) [@S1ack](https://forum.inductiveautomation.com/u/S1ack)\ **Post date:** [May 2, 2023, 10:50am UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/1 "2023-05-02T10:50:45Z")
Retrofit of HMI on older machine. PLC code exists and is working. I have a valve, when clicked opens a popup window. On that window a (2) value multi-state button. Open (control value is 1), Close (control value is two). And also an OK button and a Cancel button. Cancel closes the popup, OK executes a script to write specific integers to PLC addresses. In this case if the button control value is (1) write a 46, if control value is (2) write a 47. The valve indication is a boolean on another PLC address. All that works fine. I was wishing to pre-set the control value of the multi-state button based on the present state of the valve. So I added a custom property to the root container of the popup. Name: Status Type: Boolean Desc: Valve Status and I linked it to the PLC valve indication. Then I added an 'internalFrameActivated' script on the pop-up: ```auto # valve is open pre-select close if system.gui.getParentWindow(event).getComponentForPath('Root Container').Status: system.gui.getParentWindow(event).getComponentForPath('Root Container.Button').controlValue = 2 # valve is closed pre-select open else: system.gui.getParentWindow(event).getComponentForPath('Root Container.Button').controlValue = 1 ``` However it does not work reliably, and I think I have a fundamental mis-understanding of how to set the button property. ---
**Author:** ![justinedwards.jle](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justinedwards.jle/32/37854_2.png) [@justinedwards.jle](https://forum.inductiveautomation.com/u/justinedwards.jle)\ **Post date:** [May 2, 2023, 11:13am UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/2 "2023-05-02T11:13:50Z")
Are you using a [parameterized pop-up](https://docs.inductiveautomation.com/display/DOC81/Parameterized+Popup+Windows)? Typically ~~values~~ _ **parameters** _ are passed into a popup when the pop-up is opened rather than retrieving the ~~values~~ _ **parameters** _ after it has opened. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [May 2, 2023, 11:22am UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/3 "2023-05-02T11:22:42Z")
> [@S1ack](#): > > In this case if the button control value is (1) write a 46, if control value is (2) write a 47. You could set the values to be 46 and 47 directly, and just write the value instead of having to resort to an if/else logic. ---
**Author:** ![S1ack](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/s1ack/32/22451_2.png) [@S1ack](https://forum.inductiveautomation.com/u/S1ack)\ **Post date:** [May 2, 2023, 11:30am UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/4 "2023-05-02T11:30:08Z")
> [@justinedwards.jle](#): > > Are you using a [parameterized pop-up](https://docs.inductiveautomation.com/display/DOC81/Parameterized+Popup+Windows)? Typically values are passed into a popup when the pop-up is opened rather than retrieving the values after it has opened. At the time I wrote that - no I was not. But I had a note to look into that, and I just converted my valve popups to parameterized. but I left the status parameter binding in place. And passed the close value, open value, and valve name. Works fine. And in the time of answering your question, now I added the status..... And it works great. 🍻 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 2, 2023, 12:17pm UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/5 "2023-05-02T12:17:37Z")
> [@justinedwards.jle](#): > > Typically values are passed into a popup when the pop-up is opened rather than retrieving the values after it has opened. Since when? Well designed parameterized popups pass a tagpath, and possibly some behavior constants, and let the popup get all of its data with indirect binding. So, totally disagree. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [May 2, 2023, 12:23pm UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/6 "2023-05-02T12:23:26Z")
I try to make my windows "encapsulated", it's not a direct one-to-one definition with programming but the idea is similar - I should have to pass my popup as little information as possible and let the logic of the popup figure out the rest. I shouldn't have to figure out the data for the popup, the popup should do that, I should have to pass in as few parameters as needed. Therefore for popups that retrieve a record from the database, I should only have to pass in something like `{"id":5}` as a parameter. To make me have to provide the actual dataset means extra work for every time I need to call and open that popup. Much better to let the bindings in the pop-up do the work and to make your call as to open the window as simple as possible imo. Same thinking for popups that display values from tags as @pturmel points out. ---
**Author:** ![justinedwards.jle](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justinedwards.jle/32/37854_2.png) [@justinedwards.jle](https://forum.inductiveautomation.com/u/justinedwards.jle)\ **Post date:** [May 2, 2023, 12:33pm UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/7 "2023-05-02T12:33:02Z")
> [@bkarabinchak.psi](#): > > I try to make my windows "encapsulated", it's not a direct one-to-one definition A given system can have dozens of control valves, but I will have precisely one popup window for all of them, and they will all pass their parameters into the window. If I ever have to make a change, I will only have to make it one place. I've done a tutorial on this before: > [@Use only one window for different components values](https://forum.inductiveautomation.com/t/use-only-one-window-for-different-components-values/68062/8): > > I'm sure you've figured this out by now, but just in case, I've put together a tutorial that is specific to your usage case: Here is a popup window with 5 numeric text fields: [image] I have a list of tags that are going to be sent to the popup from various buttons, and will subsequently provide the values: [image] These are my buttons that are in a main window: [image] The 1st thing to do is right click on the root container of the popup window and select Customizers--\>Custom Properties: … ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 2, 2023, 12:38pm UTC](https://forum.inductiveautomation.com/t/vision-scripting-what-am-i-missing-here/73137/8 "2023-05-02T12:38:47Z")
That tutorial shows the passing of tag paths. I don't see where it disagrees with my statement. The statement of yours that I was objecting to implied the passing of tag **values** not tag **paths**. At least, that's how I read it, and would expect others to do the same.