How could be the Close Button "x" from Inset Windows disappear/deactivate

[Ali80]

Hello,

I would be very glad if somebody could help me with my question. In my actual project I use inset windows for controlling switchgears. How I can remove the "x" in the top right corner of the window? The problem is I use parallel a "Cancel" button in the inset window. With clicking the "Cancel" Button there starts a pick action with script, which is really necessary. But if the operator click on "x" the inset window close without a chance to run the script. Unfortunately exists also no script function like Mimic_Close() in which I could put the script when the user click on "x" (but Mimic_Load() and Mimic_Navigate() exists). 

Thanks and best regards

Ali

[BevanWeiss]

I'm pretty sure there is no way to disable the default close icon here, it's just part of the windowing toolkit option currently used by ViewX.

You could raise a feature request for something like a Mimic_Close function, it may get implemented. But that likely wouldn't be in the timeframe that you require it (i.e. it would be a multi-year thing, not an immediate thing).

You may want to consider re-architecting your functionality so that the Mimic Close activity is not critical to the proper operation.

If you tell us what you're trying to achieve with the workflow, we may be able to recommend an alternative.

In general it's not a great idea to rely upon some future action which may not eventuate (like mimic close).  If the computer turns off, or ViewX crashes (or is force terminated), then you wouldn't receive the event anyway.

[Ali80]

Hello Bevan,

thanks for your answer!! I assume like you there is no way to disable the close icon. Perhaps you have a workaround solution for me.

I'll shortly describe what the problem is:

In the mimic is a switchgear symbol which should have a blinking blue frame if the user click on it and the inset window opens. Now the user can see the opened inset window and behind in the original mimic the switchgear symbol which has a blue blinking frame. This I do in the VB script with a variable "v_selection" (bool) and set it to "1". In the inset window is also a "Cancel" button which set "v_selection" to "0" if the user will cancel his control. But if the user click on the close icon there is no chance to set "v_selection" to "0". Then the inset window was closed and the switchgear symbol frame is further blinking blue, thats wrong.

Perhaps you have a good workaround to realise the same functionality? Thank you very much!!

Best regards

Alois

[sbeadle]

I suppose what you are doing on the parent screen is to provide the user an indication of what plant area is being affected by any actions on the inset mimic. Does the inset mimic also make it clear which plant is being affected?

If you are using animations for this, are you using local REGISTRY variables to ensure that only the local client displays anything and other clients are not confused by it?

You could use a single animation REGISTRY('Plant Area','') which returns a name - different for each area (e.g. it's group FullName). So only one of the several plant outlines would display it at any time. (Each plant is animated with REGISTRY('Plant Area',".FullName") where the symbol uses a relative animation of the controlled plant group).

This way, only one plant can be highlighted, and the popup can do this in it's script by setting the REGISTRY variable it to the plant area's name. When the popup is closed, the item remains highlighted, which might not matter as no dialog is shown, or you add a cancel button which clears the REGISTRY value.

It's a compromise, unless someone else can improve on it?

[geoffpatton]

Have you considered creating a vbScript Form instead of an inset?

If your inset functionality is not to complex it could work pretty well.

[BevanWeiss]

It seems a little precarious.

What if they click on two devices and bring up two popups?

Which device should flash?  And if they push a button on the popup for the device not flashing?

I'd really recommend not using this kind of system.

I think what you might be better off doing is adding extra information to the popup to clearly indicate which device is in question.

This would trivially be the name of the device, which should be uniquely identified such as 43PU002 (i.e. the second pump in area 43).. sometimes the naming might be different like TK2_PU1A (tank 2, pumpset 1, pump A).

That would be step #1.  If the operators still find this a little challenging, then having a small depiction of the device location on the popup itself would likely help... Hopefully your mimic layout helps here, and just by taking like 2-3x the size of the pump itself you can show its relation to the area it affects... then you shrink this down by a bit and make the popup a bit larger to accommodate the image (in the top right with the device name continuing across the top of the popup is my preference).

This way if the operator opens a dozen such popups, they can clearly see which device's popup they are messing with... (due to the magic of windows it should be the one on top with full visibility of the device name and depiction).

[Ali80]

Hi Steve,

yes thats an indication which switchgear from a plant I will control. The control popup for the switchgear is the inset window, the choosen swichgear (one from 20 in the mimic) should indicate with other color&blink!

This is only a local server/client substation, there are no other clients. Therefore I can use local variables. You are right if there would be more clients the solution should be another. Perhaps with a template and an instance for each client.

I'll test it with the idea with REGISTRY ('PlantArea',) if this opportunity will solve the problem.

Thanks!!!

[Ali80]

Normaly we work only with VBscript forms for control popups. This is the first time I must use an inset window because the inset window content is full with functionality which a control popup would not fullfill. With VBscript form it would be very easy execute further script after click the close symbol. Thanks!!

[Ali80]

Hi Bevan,

unfortunately I must realise the graphics like I described. Its a mandatory customer requirement. 

Just in your last answer you have detectet my second problem which I not have communicate. This is the freedom to open more then one inset window. That should not be. In this direction I think for a long time.

[geoffpatton]

If the requirement is to not allow more than one popup windows to be opened at a time you could try the following, if the size works out.

Instead of actually opening an inset you could instead navigate to another screen instead. On the new screen embed the screen you are navigating from and make a script called DoNothing then have the embedded mimic run that script. then no buttons on the embedded mimic will operate.

Now embed your mimic that was opening as an inset on the screen. it's close button will have to be changed to do a Back command.

Yes there are down sides here, like you can not move the popup around since it is not a popup. Sometimes we have to do odd things to meet a specification.

Also have you requested they make an exception to their requirement and proposed something else?

[BevanWeiss]

This sounds similar to what we've started doing for full ASM-esque displays.  We no longer have popups.

There are one / two areas of the mimic set aside for 'Device Books' which pretty much just contain the content that would have been in the popup.

In this way:

1. No data on the base mimic is obstructed by the popup (since the space for it is pre-reserved on the mimic).
2. No operator 'mental load' is imposed on window position management, since no data is obstructed, and movement of the device book isn't required, it is where it is.
3. There's no issue with the operator inadvertently having numerous popups accidentally open or confusing between two popups, where two device books are present, they are positioned in obviously different locations, with a title showing which device is being represented by each device book
4. It natively supports not having to worry about any 'close' thing.. because unless you specifically code something to have an empty book or similar it will be displaying the last selected device.