Momentary Button, or similar

[nminchin]

I'm confused... So you have a page View displaying stuff for a single evaporator and you want to be able to change a View parameter to switch to show other evaporators?

Is something like this what you mean? (the image is just for giggles)

This is all the button scripts do:

The view.custom.deviceName and parentPath would then be used in bindings on the page to show info for the selected evaporator.
Or rather, use the deviceName to build the deviceTagPath, and use this in your indirect tag bindings.

[Orion_Williams]

Pretty much that, but I was trying to avoid scripts. I achieved it with OneShotButtons and tag bindings. I respect and appreciate the power of scripts on each component. I don't like having to navigate into them to view what they are doing or to copy/paste/modify. These buttons all write to the same tag and display the selected value, even if something else writes to it. This is what I set out to do. I don't know why standard Buttons can't do it, but I learned something today I won't soon forget. Hopefully I will be able to apply it and grow further in my Perspective studies soon.

[amarks]

@Orion_Williams

Labview, AVEVA Edge, C-more HMI, CCW, etc. all manage button functions without the need to write a script. They take the "pressed" value and apply it to a boolean tag, pressed for 1, unpressed for 0. To view the assigned tag, you simply view the properties of the component, and you can rapidly click them with the properties open to view their assignments without drilling into dozens of potential events.

To replicate the simpleness of a "traditional" HMI momentary button you can use the Set Tag Value (or Set Property) option under the actionPerformed event handler for the button. No scripting required. If you want a custom functionality that's when you need the script.

edit: sorry, I see that this is perspective now. It is odd to me that there is no equivalent Set Tag Value, Set Property, or SQL Query option for perspective component actions. There really should be so that it matches Vision. I can see why that is frustrating.

[lrose]

@amarks

There really should be so that it matches Vision.

I think it was a very deliberate choice made by IA. To disuade the use of momentary buttons in an enviroment where they shouldn't be used. The use of them in "traditional" SCADA packages is questionable, including Vision.

Even if it wasn't that, the technologies are vastly different, and the events in perspective are ment to mirror the Javascript events that back them.

[amarks]

Sure the use of momentary buttons is questionable, but the vision dialog box for buttons allows for best practice on buttons as well if you only use the set when pressed option and don't use set when released. The same should really be available in perspecitve.

I totally get where @Orion_Williams is coming from. He's looking to minizine the barriers to entry for Perspective. Forcing perspective buttons to use scripts just to set a tag value does seem like a barrier, although there are one-shot buttons that could probably handle the best practice solution.

[AIO]

Option 1: Hear about its absence.
Option 2: Support its presence.

Seems like a pretty clear cut choice from IA's side, and one I can't fault them for making. It's an adjustment (heck I posted about the same thing when perspective launched), but it's the reality.

[lrose]

@AIO

Option 1: Hear about its absence.
Option 2: Support its presence.

Option 1: Free, annoying, potentially puts off some customers.
Option 2: Costly, annoying, essentially impossible to implement in a way that always works, potential liability.

I would have taken Option 1 too.