Calendar control that does not block the GUI

[Mads]

If you click on the calendar button of a date & time control all updates of the user interface and all functions that happen to run in the user interface thread are halted/blocked.

This is, as far as I know, because the calendar is really an ActiveX control...We need a native control that does not show such behaviour (especially considering the fact that things like the run method is running in the user interface thread...).

It is quite ugly that such a fundamental control as the date & time control depends on code that will block the GUI. 

[SteveChandler]

Mads wrote:

I just do not think it's correct to respond to the suggestion that this is not worthy of an idea (or rather - a solution!) by saying that this is well known, and a sacrifice we have to live with to get other features.

---

I re-read the whole thread. Nowhere do I see Aristos saying it is not worty of an idea. I only see him explaining why things are the way they are. It is just how LabVIEW is architected. I think it is unlikely that NI will completely rearchitect the whole thing just for this. Only a small percent of their target market will ever see it and those are pretty advanced users.

I also see Aristos explaining how to completely avoid this issue. Those advanced users should have no trouble following his advice.

Maybe the solutions are a bit cumbersome. In that case maybe it is possible that a development tool could be written that would help in creating these plug-in architectures.

Hey OpenG guys?

[AristosQueue (NI)]

I'm not saying LV wouldn't be better if this changed. I'm saying changing it is a big deal. None of my comments above should be taken as "we can never do this" or "we would never do this". My goal is to try to give you guys insight into How LabVIEW Works, so that you are more aware of what you're asking for. That helps you to guestimate timelines in the event that LV does pick up an idea, and it may help you propose other solutions that would help you just as much but have a shorter implementation time.

I think a good analogy to this root loop issue is the recursion issue. For its first two decades, LabVIEW didn't have real recursion (there was a workaround involving VI Server). Massive parts of LabVIEW were written on the assumption that "the VI hierarchy can be traversed as a tree." When we started refactoring to allow for cycles, that tree became a graph. As a result of that change, I spent 18 months working on File >> Close, trying to get an orderly unload of VIs in memory. Other developers were allocated to Save, Reserve For Run, Compile, Download to Target, etc. A whole lot of resources went into that small "tree becomes a graph" change. The result was a refactored version of LabVIEW -- that still didn't actually have recursion. That took a couple versions more. In the end, a minority uses recursion, and it crossed off one item on the list of Reasons Why LV Isn't A *Real* Programming Language. Was it worth it? I think the same question applies equally well on this idea.

[bob@prolucid]

Back to the initial problem posted.

Aristos, can you confirm that this behaviour does not affect dynamic launching of class VIs?  I believe that classes do not run the UI thread but I want to be sure.

Also some feedback, I've been using LabVIEW fro 10 years and have taught the LabVIEW courses for most of that time and I am embarrased to say that I didn't realize this could be a problem.  (However, most of the plug-ins that I have written are pre-loaded on initizlization of the code and that seems to avoid any thread lock issues.)  There is a whole section of the LabVIEW Core courses that promote a plug-in/dyanmic architectrue.  I don't think this UI lock issues is covered in the course but I will definately be adding it the next time I teach that section.

[AristosQueue (NI)]

Reading prolucid's comments made me a bit paranoid that others reading this thread might miss the subtlety of this issue. So here's as clean an explanation as I can provide:

Most nodes in LabVIEW can be performed in any execution thread.

Some nodes in LabVIEW can be performed only in the UI thread. The UI thread may cooperatively multitask many of these simultaneously.

Fewer nodes in LabVIEW can be performed only in the UI thread if there are no other cooperative multitask activities going on. We call these actions "requiring root loop".

In LV 2011 and earlier, one operation that requires root loop is Open VI Reference. (I add the version caveat only because things do change and I want to be clear what versions this all applies to. Please do not read that as implying that anything will change. Likewise, please do not read this disclaimer as implying that nothing will change.)

If your plug-in system works by "User clicks on a button or chooses from a menu or takes some action and in response I load this plug-in VI", you are not affected.

If your plug-in system executes while the user interface is locked (busy wait cursor, panel not open, etc), you are not affected.

The above use cases are by far the most common use cases for plug-ins, and they work fine.

This issue ONLY affects plug-ins that are dynamically loaded into the backgorund while the user is free to click on other things. Suppose you have a loop that is handling a user interface. Independent of that, you have a loop that reads data from some source and, based on the value of that data, loads different VIs into memory. In this case, operations that require the UI thread participate in cooperative multitasking will lock out the loading of the plugin until the UI thread is no longer busy. These include tracking a popup menu, a drop menu, or showing the calendar of the timestamp control.

Being affected is not necessarily a problem for your application. The loading of the plug-in will proceed just as soon as the load can get time on the UI thread by itself -- so when the user closes the menu or closes the calendar. Most apps are fine with this -- the user rarely does anything that ties up the UI thread for a long time, and because "load from disk" is not a deterministic operation, the rest of the code cannot be dependent upon the plug-in loading within a defined amount of time. These two facts mean that most people will never be aware of this issue.

Cooperative multitasking lets most VIs do UI work regardless of what other VIs are doing. Interestingly, once an operation requiring root loop gets going, other tasks that only need cooperative multitasking can often proceed, just not another event requiring root loop. There is (at least) one operation that actually locks out cooperative multitasking: Call Library Nodes that are configured to run in the UI thread. Once one of those starts, nothing in the UI runs until the thread returns.

I hope that summary helps clarify the issue.

[rolfk]

Mads wrote:

>I've developed in LabVIEW myself continously since 1997, and have not noticed it for all this time, but then again most of the programs of ours that do dynamic instatiation of background processes and >have a GUI are more often than not used via remote clients (served by that same dynamic instatiation...(!)) instead, so the odds of a freeze is so low that it can take a long time before the >first occurrence. It is an intolerable risk though, and we will have to migrate away from it somehow.

This fact alone seems to be a pretty strong indication that this problem is not at all such a show stopper as youo seem to want to make it. Also it is not a freeze of the application but a postboning of some pretty rare and unlikely operation while a user decides to open one of those dialogs without acknowledging it.

And the root loop has been discussed extensively on Info LabVIEW several times in all those years. So it is also not an unknown thing but just some that you may have missed for some reasons. There are several places in the documentation of LabVIEW that talk about it too. So yes it exists, it can be an issue under rather exeotic conditions and it is because of that relatively unknown, despite the fact that it has never been hidden by NI in any way but they openly discussed it (Greg Mc Kaskle was one of the LabVIEW developers giving more insight into the root loop in some of the Info-LabVIEW discussions) and even documented it. Things like popup-menu handling are in fact handled in most Windows applications by a tight control loop that captures the Windows event dispatch mechanisme for the entire process. It is how Windows was designed to handle this, and requires a rather involved infrastructure in the application to avoid it.

[elset191]

I just had my DAQmx Watchdog expire because I opened a calendar browse window.  Reading through this thread it is not entirely clear to me why or what I should do to work around that. 

I've started a thread on the LV forum for discussion.

[elset191]

Thanks, Aristos.  I had just hid the button.  Didn't realize the picktime.vi was inherently different.  The impression I had reading this thread was that the browse button called that VI, and it was doing the blocking.  I'll give that a go tomorrow

[AristosQueue (NI)]

It does call that VI. The problem is with *how* it calls that VI. Calling from G code is fine. Calling from the C++ code is not. Long story there.

[rolfk]

I'm pretty sure it doesn't really call that VI. Otherwise optical changes to the VI should show up. What I think happens, is that there exists a copy of the front panel resource of this VI in one of the LabVIEW resource files and that is what is loaded and used by the internal LabVIEW dialog handler in the C++ code. Not that it makes a significant difference. Calling a dialog directly from within the C code and handling its UI interaction from there would anyways involve the root loop somehow.

[AristosQueue (NI)]

Rolf wants to get all technical. Yes. There's another copy of the VI. It's still exactly the same VI with no differences. No, we do not call a C++ dialog that looks like the VI. There's just the VI.