Darren's Weekly Nugget 05/22/2006

[tst]

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.

[HJPhilippi]

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!

Greetings,
Hans

[Jaegen]

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

I totally understand the reason for doing this:



My question was, is it worth doing something like this?:



Now, of course, in making this second picture I ran tests with and without deferring panel updates, and found the answer myself ... 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.

Jaegen

Message Edited by Jaegen on 09-29-2006 12:28 AM

[tst]

---

@HJPhilippi wrote:

I have code that must be executed (e.g. releasing file references or other resources) no matter if an error occurred.

---

As far as I know, Close or Release primitives always perform their function even if there is an error wired into them. Of course, you could use the right click option to ignore errors in the node, but I believe that does not apply to errors which were wired into the node. Another option would be to use the Merge Errors VI (in conjunction with the Clear Errors VI to preserve data flow) to have the node execute and keep the last error. Another option would be to search this site for Mike Porter's Error Fork Stacker which will keep the text of both errors.

[Ray.R]

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!

Thanks,

RayR

Message Edited by JoeLabView on 09-29-2006 07:58 AM