05-22-2006 11:53 AM - edited 05-22-2006 11:53 AM
Message Edited by Darren on 05-22-2006 11:53 AM
05-22-2006 02:41 PM
05-22-2006 02:54 PM
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.
06-22-2006 10:42 AM
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.
06-22-2006 11:17 AM
09-28-2006 01:58 PM
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?
09-28-2006 07:35 PM - edited 09-28-2006 07:35 PM
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!!
Message Edited by JoeLabView on 09-28-2006 08:37 PM
09-28-2006 10:07 PM
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.
09-29-2006 12:08 AM