Set Time dialog of Timestamp control freezes VIs

[kostya]

Greetings to all

I have met a problem (not sure if it was reported, my search gave no result).

Conditions:

LV2009 SP1, WinXP 32

Description:

when a user click Browse button of a Timestamp control, it has following unexpected effects while the dialog is opened:

1) all VIs running in User Interface Execution System become frozen
2) all VIs calling a Property Node (Application, VI, Control, etc. classes) are suspended at the call

I have found the dialog VI (<labview>\resource\dialog\picktime.vi) and tried to call it directly... works well without any VI freezing; so, the reason seems to be in some internal LV code calling it.

Any ideas how to avoid this?

Two example VIs are attached

Kind Regards

[blawson]

there is only one UI thread and only one thing at a time may access it.  Property nodes run in the UI thread because they interact with FP controls.

The reason that picktime works when you run it on your own is that it's execution system is set to "same as caller".  It seems that the timestamp control runs internally on the UI thread, so when called from the control, picktime takes the UI thread.  Until it finishes, anything that waits for the UI thread will be blocked.

There are a few other things that the user can do that will block the UI thread - activating the run time menu is one, I believe.

[kostya]

I would expect any reply from NI representatives. Is this accepted as a bug? Is there any workaround (except not using this feature at all or programming it myself)? If it is "intended behaviour" (I hope not), it makes Timestamp Browse feature useless in applications a bit more complex than trivial.

One detail more. Just for fun, I tested this in several LV versions... behavior is as reported in versions since 8.0 till 2009 SP1 but... in LV71 (good old time) the feature works as expected and does not freeze rest of code!

Kind Regards,

Konstantin Shifershteyn

[blawson]

I would call it "expected" behavior.  If you have code that cannot bear interruption, don't use property nodes in it, or other things that might need to access the UI thread, because you cannot depend on the UI thread being available in a timely manner.

You could probably work around this by opening picktime (you've found where it is), going to its VI properties under Execution, and changing "same as caller" to "normal".  This will make your code dependent on having that change present in the local vi.lib

[ErikL68]

This problem exists at least through LV 2013 as I just stumbled upon it.  Having people avoid using Property nodes in important code would prevent things like setting a display to blink due to a condition that needs attention, etc., simply because somebody left the Timepicker.vi displayed (users are so unpredictable).  I tried to modify the picktime vi to pick a different execution engine,but it had no effect on the problem.

Good to know about how using Property nodes carries this risk though.  NI's own post I found covering the topic doesn't mention this potential issue, and knowing all labVIEW UI is single threaded is not common knowledge.

As was pointed out, this is a simple fix, so I'm very disappointed that NI hasn't done so in the four years between LV 2009 and LV 2013.

p.s. - I started looking through the Picktime.VI and the wiring is complete spaghetti, likely due to being written in the era of 1024x768 resolution monitors.  Also, the Leap Year / Not Leap Year calculations are wrong in respect to years divisible by 100 and not divisible by 400.  Ah well.  One more thing to fix.

[ErikL68]

Here's the Picktime fix.

Also - I tried calling Picktime directly while leaving the VI execution engine as "Same as Caller" and the problem is not seen.  Go figure.  Additionally, when called by the Timestamp control with my test VI trying to also continue writing to a Value Property, the CPU utilization shoots up horribly.  Another reason to fix it, even if your code won't break due to the property updates being suspended.  I've attached my simple LabVIEW 2013 VI.

[tst]

My understanding is that the time picker dialog freeze is due to something called the root loop, not due to the UI thread, but I never looked closely at how exactly it behaves. You could start with this thread and follow the various links for more info - http://forums.ni.com/t5/LabVIEW/Root-Loop-Time-Date-Browse-and-DAQmx-Watchdog/m-p/3144266#M905059

[Hooovahh]

Yup root loop, here is another article talking about it.

http://www.labviewcraftsmen.com/blog/the-root-loop

Edit: Bonus idea exchange

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idc-p/141...

[ErikL68]

I checked out the Craftsmen blog entry regarding the Root Loop, and they have an example showing the context menus of other controls causing issues too - controls including the Path control, combo box, Enum, etc.  I found no such problems, at least not in my simple test VI.  Had these too caused an issue, I would have accepted a strongly worded warning about it, but since they don't, I see no reason why it hasn't been addressed with the Time Stamp control.  I'll definitely be voting for this to be fixed.

[Ben]

I want to say I fought to get that fixed but in what version?

Check in LV 2015 to see if the picktime is fixed now.

Ben