LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
altenbach

"Defer Panel Updates" within sequence frame so configured

Status: New

(not really related to this idea)

 

Deferring panel updates is a tedious procedure, requiring a panel reference (not intuitive to get!) and a couple of property nodes. However, deferring panel updates is sometimes very important. For example when coloring the fields of a large table according to their values, a serious performance impact is encountered unless we defer panel updates. There are many other situations where panel updates should be suspended temporarily, especially if property nodes are used in a tight loop.

 

My suggestions is to make flat sequences a little bit more useful by adding a new function to the right-click menu of each frame: "Defer Panel Updates". Now a new connector will appear on the frame that accepts a panel reference. If left unwired, this applies to the panel of the current VI, but we can wire a reference to any panel we desire (useful for subVIs). There should be a visual indication indicating that updates are deferred, e.g. a slightly different background pattern (e.g. faint checkerboard or similar). Note that this idea does not clutter the palettes with a new structure, but simply extends the functionality of existing elements. Let's put those sequences to some good use!

 

During execution of such a frame, the panel updates are deferred and automatically enabled again once the frame ends. The configuration should be "per frame" of a multi-frame flat sequence.

 

This has many advantages over the current situation:

 

  • It is immediately clear what part of the code executes during the deferral
  • The deferral is clearly delimited and it is not possible to accidentally forget to re-enable the updates
As an example, here is my subVI code to color the fields of a large correlation matrix (located on the main VI) according the respective value so we can easily pick out where correlations between fitting parameters are a problem.
TOP: current solution. BOTTOM: how it could look like with this idea implemented.

 

 

13 Comments
dthor
Active Participant

I don't use Defer Panel Updates (at least not right now), but **bleep** this is an excellent idea.

Intaris
Proven Zealot

Should we limit it to flat sequences?

 

Ever process a graph legend with a loop?

 

Ever process a table with a while loop?

 

Of course we could wrap these in a flat sequence strcuture but we could also make it a general feature of the structures.

AristosQueue (NI)
NI Employee (retired)

I'd be more in favor of putting another pair of border nodes on the Inplace Element Structure, even though that would start making the IPE stray from its intended purpose. That way we don't start encouraging the use of Sequences, which would cloud our message to new users about avoiding sequences. And on the IPE, I would sooooo make it take a VI refnum OR a Panel refnum.

 

I don't think putting it on loops is a good idea. It could be seen as ambiguous. For loops, do you mean to defer at the start of each iteration and undefer at the end of each iteration, or did you only do it at start of first iteration and after last iteration?

David_L
Active Participant

I like the idea of having an easier way to do this, but I agree with AQ about the problem of making any of the structures stray from it's purpose.  The defering/underfering of panel updates is useful but really doesn't have anything to do with IPE, sequence, loops, etc.  Perhaps an idea would be have a new structure for odds and ends like this.  Or maybe this is too much work involved for something that already has an implementation...

Darin.K
Trusted Enthusiast

How difficult (or impossible) is it to make deferring updates a property of an object instead of a panel.  You could use it before and after a loop, or series of Property and Invoke Nodes.  No digging around for Panel references, but still the potential to forget to stop deferring (same as now).  Maybe there could be a test for that in the VI analyzer.

David_L
Active Participant

Darin, I like that idea.  It also has the benefits of being able to defer updates of only certain controls/indicators but not everything on a panel.  This way you can make many changes to graph properties, but still be able throw on an emergency LED or something.  


Probably should be a new idea...

Intaris
Proven Zealot

Go for it Darin, sounds like a great idea.

Darin.K
Trusted Enthusiast
Oh great, now I have to go and draw a nice picture....
Intaris
Proven Zealot

🙂

JackDunaway
Trusted Enthusiast

Something that has always bothered me is when parallel processes are calling Defer/Undefer on the same panel. Setting "Defer" to True creates a lock on the panel updates, disallowing LabVIEW from redrawing the panel. The mutex is unlocked by the very first "Defer" set to False, which is not the desired behavior. The actual desired behavior is to Defer with the very first Defer=True call, then Undefer on the very last Defer=False call.

 

With a new atomic Defer structure, a semaphore could be created where all parallel Defers increment and decrement the DeferCount manager, and Panel Updates would only occur when DeferCount==0.

 

Does this make sense? Is my terminology/concept sound? I think this Idea not only provides an excellent graphical grouping for deferring panel updates, but it also eliminates the need to brew your own Panel Defer Manager.

 

I'm down with either a new structure or a new node on an existing structure.

 

(In response to the Defer for a single control - great Idea, and actually diminishes the concerns above)