Pass dynamic value to dock parameter

Ignition
1

Perspective 8.0.16

What’s the best way to pass a dynamic value to a dock view parameter? Right now I simply call

system.perspective.openDock("dockID", params = {"HeaderText":self.custom.HeaderText})

On each view onStartup. This works, but not if I want to change the value after the view is loaded. Is it ok to call system.perspective.openDock() each the value changes? I assume it doesn’t actually open a new instance, but just updates the current one?

At any rate, is this the best option?

2

You could also use a session custom property. That way it would update in real time when you write to it.

1 Like
3

Simply just pass message to your dock each time you want change params

1 Like
4

How would a session property work? The dock parameters aren’t bindable.

5

That was my next choice. I’ll try and see which works best.

6

You can create custom property in dock view and bind them to session property.
And each time only update session property.
But I believe it is bad practice. Just use messaging system and you will enjoy it a lot.

7

How? You can create view parameters in a dock view but they are not bindable.

Just wondering for curiosity sake. I did use messaging, works very well.

8

As I told before create custom property which are bindable not params

9

We had a project where we wanted a parameter to be shared to docks on the same page, but not the session (user could have multiple tabs open and look at different things.)

All primary views have a custom property that we want shared, and that property has an on change script that just does this:

self.page.props.myPageProp = currentValue.value

even if page.props.myPageProp doesnt exist, it will get created when this runs.

The biggest problem with this is there’s no easy way to make sure this happens on every primary view, other than manually going through them and making sure its there.

10

I still don't understand where and when to use messaging over session properties (or page url params for that matter). But the reason I would tend to go for a session prop is because it's a common source for a cross-view value to live, which will be there regardless if the view/page is changed or not. If you navigated away and back to the page, will the header text still be the same?
I see messaging as less fool-proof, similar to comparing bindings to scripted property change events in Vision: I will also preference bindings and expressions to scripts, as they're far more reliable and you know the value of the thing will always be the value of the result of the expression. The same however can't be said for scripts. Open to more insights though as I'm definitely still a n00b at Perspective!

11

Hi
For me using session property is like using a lot of global variable in your c++ project instead of encapsulated variable inside the class. Less manageable.

  • if you want to compact your resource and send to some one you only have to export your views not session property if you use messaging system.( No need from r session property)
  • if you use too many sessions properties it become messy and unreadable specially for large scale project.
  • I only use session for really global things in perspective. For example record the open popups list. And close them when changing view.
    A real example:
  • consider 500 moving points on perspective map and want to update their lat and lng from your tag.
    The points create base on existing tag by script on the fly so there is no way to bind anything to them.(map.layer.view)
    The only event base option to update lat and lng is to use messaging system.
    Or using a timer in view to loop throughout the tags and update map property which is totally bad idea for performance compare to messaging which is event base and excited on sperate thread.
1 Like
12

I recommend using session properties if a single value is referenced in many places throughout the project. Messaging is best used when a value is only used within one or two places, but also if that value is used within embedded views, Docked Views, or Popups, since those Views can't "directly" communicate or have bound values between themselves.

Messaging is also useful when you want to send a message to a DIFFERENT session (chat is a good example).

While use of a session property is perfectly valid here, the primary drawback to using session properties in my opinion is that large projects can easily have hundreds of properties. When this happens, it's hard to keep track of property locations within the Session Property Editor.

2 Likes