LabVIEW

[Darren]

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.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 05-22-2006 11:53 AM

[shoneill]

Well well,

I don't know about anyone else, but I personally find the piece of information that an unwired property node implicitly linking to the current VI as very useful.

To Quote Walter Sobchak "I did not know that".

I always went the route of "OPen Reference" wired with the path constant for the current VI.

This is much neater.  Especially in this particular application.

Thanks once more

Shane.

[Darren]

No problem, Shane.  When I first took a screenshot, I did not include that comment.  Then I looked at the code and realized some people may not know the unwired reference trick, so I included a comment describing that trick, too.

For the benefit of anyone doing a future search of the forums (which would not search the text in my screenshot), the trick we're referring to here is the fact that a property/invoke node of the VI class with an unwired refnum input will be implicitly linked to the VI containing the  node...similar to how a property/invoke node of the Application class with an unwired refnum input is implicitly linked to the Application Instance that contains the VI containing the node.

-D

[HJPhilippi]

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.

Greets,
Hans

[Darren]

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

-D

[TiTou]

An interesting 31-posts-long thread about "which reference needs to be closed ?"

[Jaegen]

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?

Jaegen

[Ray.R]

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!! 

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!! 

Thanks,

RayR

Message Edited by JoeLabView on 09-28-2006 08:37 PM

[Darren]

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.

-D

[Matt_W1]

One thing to keep in mind with defer panel updates is to be sure to stop deferring the updates. For instance in Darren's example if the UI updating had generated an error, and passed it to the property node to stop deffering, then the deffering would continue and the VI would appear frozen. Also the VI can still recieve input from the user while deffering. So Setting the Cursor to Busy will also stop the user from interacting with an UI in mid change.