LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

Calendar control that does not block the GUI

Status: New

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. 

32 Comments
PhillipBrooks
Active Participant

I'm pretty sure that the date/time picker is NOT an ActiveX control; I think it is implemented this vi:

 

C:\Program Files\National Instruments\LabVIEW X.X\resource\dialog\picktime.vi

 

This vi's Window Behavior is configured as modal, so the behavior you describe would be correct.

 

I wouldn't change the behavior without consulting with NI first...

 

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Mads
Active Participant

A modal window will not block the user interface the same way the date and time control's calendar does, in fact a modal does not block much else than access to other windows in the same app. The calendar on the other hand will set the user interface in an un-idle state and this will e.g. block the execution of all Run Methods in your application.

 

The reason why I mentioned ActiveX is because in the old days when it was relatively easy to grab the run-time engine files that you needed and make your own installer, then that particular part of the date and time control would no longer work. It needed some component that was not included in the lvrt.dlls etc. (I'm not all sure why I believed it was an ActiveX component though.)This might have changed in later versions of LabVIEW, but the VI you mention has password-protected sub-VIs that still might contain troublesome code, or it could be the way this VI is called that causes it to have such a potentially severe impact.

 

The title of the idea is somewhat incorrect though - you will still get user interface updates in the background when the calendar is up, but it affects the state of the user interface in a way that blocks things that wait on an idle state...like the run method.

Mads
Active Participant

I see wrote that all updates in the user interface is halted...again - that part should have been left out, and the title should have focused on the fact that methods e.g. that rely on the user interface to be idle are halted by the calendar.

AristosQueue
Proven Zealot

I don't know why the UI block is happening, but Brooks is correct about the picktime.vi being the one that appears when you click on the calendar button. There's no ActiveX involved (after all, the Timestamp does work on non-Windows platforms).

 

Someone else will have to come up with an explanation of the UI block... that's outside my knowledge.

 

Mads: if you want to correct the text or title of your original post, click on Idea Options at the top of the page and use Report To Moderator -- ask them to make the edits.

Mads
Active Participant

I tried editing picktime.vi to see if perhaps I could track down which part of it it is that blocks everything...(took a backup of the original first) but none of the changes show up, it is as if that is not the VI that is shown. I tried restarting LabVIEW etc. after the edit, but nothing.

 

I have not done any tinkering with the resources before though -...is there an obvious reason why changes are not shown (if that indeed is where the calendar of the timestamp control is from?)?

PhillipBrooks
Active Participant

@Mads

 

I use a private copy of this VI in my own code where I manipulate the title bar and hide the help button.

 

I tried editing the original picktime.vi and didn't see the changes either. Exited and restarted LabVIEW, no luck.

 

I wonder if there is a second copy of this VI in some other location or maybe the VI is compiled into a DLL that is used by the development environment?

 

Hmm....


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

somebody_that_i_used_to_k
Trusted Enthusiast

This problem manifests itself in other ways. KUDOS. This is a biggie. Perhaps a new Idea should be created, because others (like I did) may skim over this when they see "Calendar Control".

 

Watch how context menus block the VI Server from dynamically launching new VI instances:

 

 

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Mads
Active Participant

Ouch, I had only seen this with the calendar.

 

The fact that all these menus do the same is just mindblowingingly bad....wow. Maybe we've gotten too used to be able to dynamically launch things in LabVIEW. Smiley Sad Unless it is a process that can wait indefinetly, or the software is run as a service with no GUI, it's not really possible in a reliable way.

 

I did not put any pictures or video in any of the two ideas related to this problem, and it's obvious that impact of the problem is not conveyed good enough by their naming either. I think a fix of this issue should be on top of the list for all LabVIEW-programmers.

Mads
Active Participant

The name of the related idea kind of says what needs to be fixed - but it does not scream out what the implications of the problem are. What do you think we should name the "new" idea to really get people's attention? Jack, your video might be good to include as well (if you want to, it's OK with me if you post the revised idea in your name).

MIG
Member
Member

This is basically the same problem as this idea i.e. the "root loop" problem.