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. 

[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.

[AristosQueue (NI)]

elset191: There is not a direct workaround other than "do not use that control." Your closest workaround that I know of would be:

1. Hide the Browse button on the time stamp control.

2. Add a new button to your panel that looks just like the timestamp's browse button.

3. When users click that button, run this VI:

          resource\dialog\picktime.vi

4. When that subVI returns its output, set that as the value of the timestamp control.

That will give you a control that avoids the root loop issue.

[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.