Perspective Workstation Primary Display

I've dug around and I'm not finding an answer anywhere unless I'm overlooking something.

Is there a way to retrieve the monitor number (ideally), or a boolean property of if the view is being displayed on the primary display vs a secondary display? I don't know if this will matter or not (I have yet to test it), but we're putting the audio component in the header view of our page so that it's always available to be able to trigger it based on an alarm status tag. What worries me is that if one monitor's view starts playing slightly before the other monitor's view that we'd get this echo-y alarm sound going off. Allowing us to only play this on one header would prevent it completely, but being able to retrieve the monitor number from Perspective Workstation would allow much more capabilities in other aspects as well.

I could be wrong, but from my understanding no.

Vision would probably be capable. Web browsers just don't have that kind of access to the OS for many reasons. So Perspective is limited in that sense.

I know browsers don't, but Perspective Workstation supports multiple monitors and even lets you "identify" them in the app, so I was hoping it was something that could be retrieved from Workstation.

Gothca, it is possible. Check out this hook I found in the SDK
MultiMonitorUtil (

I think that's for Vision, and don't know if that works on Perspective.

Yeah I missed that. was just looking for it. Can't be done in perspective. couldnt find antyhing in the sdk

You can think of Workstation as being IA's implementation of a browser, so it can have some access to that type of information. Where as, perspective is being ran in a third-party browser and so does not have that same access.

We don't currently expose any ability to run code locally in Workstation, though we're considering it for a future release. In the short-er term, we could probably expose this is a session or page property, but as far as I know it's not currently set anywhere.

1 Like

That would definitely be handy to have. This along with other client properties would probably help out with some of the issues with client verification/security that @pturmel has talked about in other threads also. While local scripts are ideal, read-only properties like this are definitely helpful for this and other use-cases.