FTView studio transparent rectangle object to disable screen

I have a requirement to implement in factory talk view studio se
It is to block the user from interacting with the display, sort of disabling touch screen.

Can I use a transparent rectangle and visibility?

I would make a User screen that only showed status's.

On it there would be one button to change screens to the supervisor screen that is password protected.

Thanks Aabeck, it’s a good idea.

If transparent layer doesn’t work then I have to consider this method

Why not just use security account groups/users and assign "Visibilty" animations to buttons.

duplicating screens makes for hard work if you need to modify...

Yes. Only foregound objects can be pressed and only if visible (the property).

Animate the "visibility" of the transparent object and you can enable/disable the buttons.

Just make sure it is the foreground object.

mahone said:

I have a requirement to implement in factory talk view studio se
It is to block the user from interacting with the display, sort of disabling touch screen.

Can I use a transparent rectangle and visibility?

Click to expand...

One easy way to prevent touch is to create an end key, make it transparent, and then place over the objects you want protected. The visibility is based on user logged in.

thanks a lot all of you..

i used the End Key method as suggested by Phrog30 and all okay now.

I should have mentioned that the object has to be a touch enabled thing such as a button.

Phrog30 said:

One easy way to prevent touch is to create an end key, make it transparent, and then place over the objects you want protected. The visibility is based on user logged in.

Click to expand...

Isn't that more work than attaching "visibility" to the button itself ? And not just "more work" for the programmer, it's also more work for the HMI to resolve all those extra buttons

IMHO, why show a button that can't be pressed ? You can always put a static object like a greyed-out button (converted to wallpaper) where the button goes when visible if you do want it to be "seen".

And if you go around making objects transparent, what happens when you move the underlying button, you'd have to remember there is a transparent button lying on it, move that as well, AND make sure it is top layer

Daba, yes it's more work (seconds of work).. It's a work around for not having an enabled property. There are many times you want to show objects but not allow use. You obviously haven't had a need, at least two in this thread have. Grouping makes sure everything goes together if moved. Using the object explorer/browser makes it easy for everyone to see the hierarchy. I give everything a useful name.

Phrog30 said:

Daba, yes it's more work (seconds of work).. It's a work around for not having an enabled property. There are many times you want to show objects but not allow use. You obviously haven't had a need, at least two in this thread have. Grouping makes sure everything goes together if moved. Using the object explorer/browser makes it easy for everyone to see the hierarchy. I give everything a useful name.

Click to expand...

I most certainly have had the need to disable buttons for unauthorised users.

Each to their own method, but I still don't like the idea of the display scan having to parse dynamic objects that (a) needn't be visible to an unauthorised user, (b) will slow down the HMI scan, (c) use more memory, and (d) could cause confusion to an unauthorised user, as he may be pressing "hidden" (by the transparant overlay) buttons that won't work...

I would much rather place a wallpapered image of the button, perhaps with a red line through it to show it is not available for use, and make the available real buttons visible by user credentials.

The recommendations for FTView, and indeed any HMI or SCADA system, has always been to minimise the number of active objects on the displays. With your method, if you had 40 buttons you had to disable, you would need an additional 40 transparent buttons to effectively disable the actual buttons. My method has zero overhead, and would execute faster.

First, it's not my method. I got the trick from Rockwell as that's how they were doing it in a faceplate. Second, well, I don't have a second. I have better things to do than a back and forth with you.