[Question] Is there a way to access Perspective Views in the Script Console?

Using the system.gui.getWindow(‘Window Name’) call, one can access vision Windows and their subsequent components. Is there a similar way to access Perspective Views in the Script Console?

(edit: Clarified question.)

There is no function to access Views in such a manner.

Views and their properties should be addressed via property-accessing:

self.view.custom.some_property

An Embedded View (named ‘EmbeddedView’) would be accessed in the following manner:

self.view.getChild('EmbeddedView').custom.some_other_property

There’s no ‘self’ in the script console… :neutral_face:

Whoops - I read the whole Thread title except for the last word… :grimacing:

There is absolutely no way to access anything perspective in the script console because - as you just said - there is no self in the Script Console. Everything in Perspective needs some idea of context (am I checking my properties? Am I checking the properties of my sibling/view?)

That being said, the system.perspective function calls will not work in the Script Console either because they all require a sessionId or pageId behind-the scenes. This is either provided by the user to target a specific page, or it defaults to the sessionId/pageId currently in use. You really don’t want to try something like system.perspective.navigate(view='my_view') in the script console - in fact, the script console even notifies you that there is no system attribute ‘perspective’ available in the Script Console when you try.

1 Like

You really don’t want to try something like system.perspective.navigate(view='my_view') in the script console…

I already have :grin:

Thanks for the explaination.

1 Like

I have a related problem. I am using Perspective and trying to refreshBinding on a component’s property. This component is on the view that is the main window, but I want to be able to do it by clicking a button on a popup.

How can I reference components on the parent view from its popup?

You cant, you will have to send a message on the component and a messagehandler with the same name on the main window
https://docs.inductiveautomation.com/display/DOC81/system.perspective.sendMessage

1 Like

so to be clear, from the Script Console, you cannot access any session or view props/custom for testing?

Correct.

then... :frowning: how do you actually test-flight scripts?? makes the console window pretty friggin' useless because you can't test an idea against any actual data.

@pturmel i was both hoping you would and would NOT answer... because you'd either Show Me The Way or Horribly Crush My Hopes. :laughing:

Create a gateway message handler. Put your test code for pure gateway scope stuff there, however you like.

For Perspective sessions, create a session message handler. Relay from the gateway message handler to the session handler.

For Perspective pages, create a message handler on your view, at page scope. Relay from the gateway message handler.

With the above set up (and saved), use system.util.sendMessage() and/or system.util.sendRequest() in the designer.

For Perspective views, consider making an extra button with an action event handler.

1 Like

that's an insane amount of circuitous effort for what should be base functionality in a development tool. what's the reasoning behind siloing the Script Console? it can't be security because i had to log in to the damn thing in the first place so i couldn't access anything i didn't have Roles or permissions for.

Perspective is four years old. The script console is a tool developed to go with Vision, which is (counting pre-Ignition) almost 20 years old.

Perspective scripts run in the gateway. The script console runs in the designer. That is an intractable problem for Perspective. It's perfect for Vision, for which scripts are run local to the client.

Don't hold your breath. When a solution comes, it will probably be some kind of remote gateway console (entirely separate from the current designer script console).

@ian.sebryk You can cast a vote for this feature here:

Yeah. Don't hold your breath waiting on that.

Yeah... I don't think anybody here will argue that the feature would be useful; it seems obviously useful.

However the prospect of adding an endpoint or RPC call, the explicit purpose of which is literally remote code execution, is inconceivable to me.

3 Likes

Yeah. The counterargument is "you can already easily RCE the Gateway via the Designer", so a 'Gateway Script Console' is really just making it slightly easier, and I think we are still planning to do it, but I share the same kneejerk oh no reaction.

2 Likes

It'll never get a +1 from me :stuck_out_tongue:

Huh. Decades of "separate logic from presentation" and various CQRS-type patterns and whatever unit-test flavor of the week we are using make putting logic in a layer where it can be called from various places (vision, perspective, console, a fictitious IUnit framework) like an obvious thing. At least to IT developers if not OT engineers...

Lack of refactoring support OTOH...

1 Like

fair enough. i'm refactoring like mad here, so i fully appreciate that. tech debt is an ugly thing. :stuck_out_tongue:

1 Like