New "Disabled"-Property for Frontpanels

[Andi_S]

I'm really missing a "disabled"-property for the complete front panel:

I think I don't need to explain what it shall do but maybe a word to the non-working workarounds:

1. set busy / unset busy: Does not work if the calling VIs front panel is shown within a sub-panel-container

2. getting a ref to all FP elements and set them to busy in a loop: a part of the running VI could change the disabled-state of a control while the complete FP is disabled. This would unlock the FP partly or disabled controls could be set to enabled mistakenly after enabling the whole FP again.

[AristosQueue (NI)]

This sort of lock out is generally achieved by putting whatever UI update code you need into the frame of the event structure where (by default) UI interaction is blocked until the frame finishes execution.

You also have the property on the VI for "Defer Panel Updates" which may cover your concerns.

[fabric]

Kudos.

AQ: The problem with your suggested workarounds is the lack of visual feedback that the panel is disabled. I'd really appreciate a solution that dims the panel somehow, just like disabling a specific control.

[Andi_S]

AQ: the workaround would only work well in producer-consumer architectures. In many other architectures it would block the whole VI execution and not only the Frontpanel.

[AristosQueue (NI)]

fabric:

> the lack of visual feedback that the panel is disabled. 

I cannot think of any applications that visually show that other than the Busy mouse cursor. Do you have an application to point to that we could use for comparison? If you are truly blocking the whole window, that's how you should do it. Graying out is for when part of the UI is on hold but not all of it.

Andi_S:

> In many other architectures it would block the whole VI execution and not only the Frontpanel.

I don't follow. Either you aren't understanding what I'm suggesting or I'm not understanding your architecture.

If I need the panel locked out while I'm doing work, I do it in the event structure. That's exactly what it is designed to do. It doesn't impact any other part of the VI.

[X.]

Make a transparent (or slightly transparent) button covering your panel Visible/Invisible?

[Andi_S]

AQ: An example with the JKI-State-Machine: In one state there is the event structure, in the other states the code to execute. An event causes just the execution of a more or less pre-defined sequence of states. Execution of the event-handling-frame itself is only a very little part of the complete sequence of execution.

X.: I also tried this but there are two lacks:

1. keyboard-shortcuts will not be blocked
2. If a new control / indicator is added it will be in front of the "covering" button. A function for programmatically changing the z-position of a control does not exist.

[AristosQueue (NI)]

> Execution of the event-handling-frame itself is only a very little part of the complete sequence of execution.

That is the common pattern in order to NOT lock the UI. But if you need to do work that locks out the UI, you should do it in the event frame. That's the whole point.

[Andi_S]

At larger projects that's just not possible or requires a complete change in the architecture.

[AristosQueue (NI)]

None the less, it is the correct way to handle this. If we created the new property you're asking for would probably open you up to timing gaps in which UI events could be generated before your UI is set up in response to the previous event. 

I will take your word for it that you would have to make a substantial architecture change, but please consider this option: If you normally throw to another loop, go ahead and throw to that other loop in the event frame and then synchronously wait for a response from that other loop ... easiest way is to generate a local queue refnum, send that to the other loop along with payload, then do a Dequeue with no timeout... the other loop does its work then enqueues result back into the queue. The event frame dequeues, releases the queue, and goes on its merry way.

Obviously, if you don't usually throw to another loop but just handle things in the current loop, then just go ahead and handle the event in the event frame without throwing to yourself.

If neither of those work, a substantial rearchitecture may be required to do what you are requesting.

[crossrulz]

Personally, if something is going to take that long, I will use a modal window that has a progress bar.  It does two things for you: 1) disables the front panel on your main VI, 2) shows the user that something is happening.