Darren's Weekly Nugget 05/22/2006

Darren's Weekly Nugget 05/22/2006

Post by Darre » Wed, 24 May 2006 02:10:09

This suggestion has been made numerous times on the LabVIEW forums, but I wanted to make it an official nugget today.  If you have something going on in your UI that takes a long time to update (one of the most common examples is populating a tree control), you should surround your code with the "Defer Panel Updates" operation.  By setting this property on the front panel, you can tell LabVIEW that you do not want it to "draw" anything on the panel that requires drawing.  This will actually speed up your code quite a bit when doing something drawing-intensive like adding hundreds of items to a tree control.  Then, once your updating is done, you can enable panel updates again.  To add a touch of usability, you can use the Set Busy.vi and Unset Busy.vi to give an hourglass cursor during the updates so the user can't attempt to change anything else on the panel (and thus be puzzled as to why they aren't seeing updates).  A screenshot of a very simple implementation of the Defer Panel Updates property and Set/Unset Busy VIs is shown below.
<img src=" http://www.yqcomputer.com/ ">
-D P.S. - Check out past nuggets <a href=" http://www.yqcomputer.com/ ;message.id=1669" target="_blank"> here</a>. Message Edited by Darren on 05-22-2006 11:53 AM


Darren's Weekly Nugget 05/22/2006

Post by HJPhilipp » Sat, 24 Jun 2006 01:10:06

One thing I ask myself when I see implicit object reference creation (similar to Dim myObj As New Anything in VB formerly): When is the object ref implicitly destroyed? When the VI stops? Or when LV is shut down? Having larger apps with memory consumption and reference management overhead etc. in mind.
I prefer creating references manually and closing them by hand, too - at least to have the illusion that everything is under my control.:smileywink:


Darren's Weekly Nugget 05/22/2006

Post by Darre » Sat, 24 Jun 2006 01:10:09

When the VI that generates an implicit reference goes idle (i.e. stops running), the reference is closed.

Darren's Weekly Nugget 05/22/2006

Post by Jaege » Sat, 30 Sep 2006 04:10:11

Sorry to awaken a long-ago-put-to-bed thread, but I have a question about this:
Is this (using "Defer Panel Updates") only worth doing when you're doing a lot property/method writing for a single control?  What I mean is this: I have a section of code that writes to a few properties for a bunch of controls - should I defer panel updates during it?  In fact, it's in the "Display State Change" event for an XControl.  I think all this will do is delay the actual graphical updates until all the properties have been written, then do them all at once, as opposed to the tree control example, where multiple property writes to the same control would cause that one control's graphics to redraw many times otherwise.  In my case, there's no way around updating each control separately, and all this will do is consolidate the graphics activities.
I hope my question makes sense.  Obviously any improvement won't be as drastic, but is there still an improvement to consolidating all the graphical processing?

Darren's Weekly Nugget 05/22/2006

Post by JoeLabVie » Sat, 30 Sep 2006 09:40:07

Hot diggiddy dangh!
Well I didn't know that either.  Been working with reference up the ying-yang and here we go... a piece of knowledge worth being a nugget of it's own!!  :o
Thanks Darren!  Wow.. the tings you learn in this place.  :)
And thanks for the actual nugget.  I actually have an immediate use for that...  Except!!!!  I need it in LV-7.0 & LV-7.1. 
Can this be implemented in the earlier versions as well??
And I'll have to read TiTou's post on closing references..
And thanks Jaegen for re-awakening this thread... I hadn't seen it!!  :o
:DMessage Edited by JoeLabView on 09-28-2006 08:37 PM

Darren's Weekly Nugget 05/22/2006

Post by Darre » Sat, 30 Sep 2006 12:10:07

To answer the previous two replies:
Yes, deferring panel updates will keep *all* controls on the panel from updating until you undefer them.  I imagine this would be desirable behavior if you don't want your users seeing the "indeterminate" state, where some controls have the "new" values, but others haven't been updated yet (i.e. are still showing "old" values).
Yes, Defer Panel Updates is available in 7.0...I'm just guessing here, but it's probably in 6.1 too...not so sure about 6.0, though.

Darren's Weekly Nugget 05/22/2006

Post by tst » Sat, 30 Sep 2006 15:40:08

JLV, the property is there in 6.1.
Jaegen, if I remember correctly, updates to the screen are always put off until *something*. Basically, I think it's timed (i.e. N times a second), but it's probably also synchronized to the BD code (e.g., if you're in the middle of executing certain nodes, wait on updating the display). You could probably test this by using a Value property to insert a lot of data into a control and then add a property before it and see how it responds.

Darren's Weekly Nugget 05/22/2006

Post by HJPhilipp » Sat, 30 Sep 2006 16:40:08

Good point, Matt! With shifted error handling, one should have the try {...} catch {...} finally {...} construct of other programming languages in mind, that is: I have code that must be executed (e.g. releasing file references or other resources) no matter if an error occurred. For this reason there's code at the end of the line that I'd simply not wire to the shifted error cluster, like enabling frontpanel updates again in Darrens example.
I always wonder if LabVIEW will have a more sophisticated error handling one day. The mentioned try {...} catch {...} finally {...} construct for instance could be realised with something like a 3-frame error sequence or so!

Darren's Weekly Nugget 05/22/2006

Post by Jaege » Sat, 30 Sep 2006 16:40:09

Sorry, I really didn't do a very good job describing my question ...

I totally understand the reason for doing this:

<img src=" http://www.yqcomputer.com/ "> My question was, is it worth doing something like this?:

<img src=" http://www.yqcomputer.com/ ">
Now, of course, in making this second picture I ran tests with and without deferring panel updates, and found the answer myself
:smileytongue: ... The answer is yes.  For the second case, with 19
individual controls (i.e. no clusters, just numerics, booleans, and strings) on the front panel, it took
about 300 ms without deferring, and about 100 ms with deferred updates.  Of course YMMV, especially with different properties, but this does seem to make a fairly strong case for liberal (though careful) use of the "Defer Panel Updates" property.JaegenMessage Edited by Jaegen on 09-29-2006 12:28 AM



Darren's Weekly Nugget 05/22/2006

Post by JoeLabVie » Sat, 30 Sep 2006 21:10:08

Thanks Darren & tst,
I hadn't explore the "Cursors" under Application Control.  That's where I found "Set Busy.vi" & "Unset Busy.vi". 
I read the other posts.  There's very good info in this thread!
RayRMessage Edited by JoeLabView on 09-29-2006 07:58 AM