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
Darin.K
Trusted Enthusiast
altenbach
Knight of NI

(Wow, I go to the NITS for a day (no internet access:() and we have a page of comments! ... :))

 

Instead of Darin's idea, I would still like to keep my current suggestion, but with the following modifications:

 

(1) It does not have to be a sequence frame, the "defer panel updates" option should be available for any structure (e.g. a FOR loop for a typical use case, a case structure, a sequence frame, etc.)

(2) The reference connector should take several kind of references: A: Panel ref., B: VI ref., C: Object ref. (e.g. a graph or table)., 😧 etc.

 

Just throwing out some ideas...

GregSands
Active Participant

I've given my kudos already (to both these ideas) because I agree with the intention, however I'm just wondering whether an alternative solution would be to create a Defer Updates primative/function, rather than either overloading a structure with something that only tangentially relates to its function, or creating new properties for objects.  The primative (or probably pair for set/unset) could have just a reference connector and error terminals, where the reference defaulted to the current VI's panel, and could take any of those reference options mentioned (panel, VI, object, etc).  The VIs Set Busy and Unset Busy cursor routines come pretty close to this, and perhaps the Defer Updates idea could be merged into these.

 

One advantage of the structure modification is that it enforces the set/unset functionality, but there are a number of other paired operations that could be likewise overloaded onto a sequence structure, so why is Defer Updates so special?