To download NI software, including the products shown below, visit ni.com/downloads.
1. Overview:
This VI This example illustrates how to take control of the computer away from the user and then give it back
2. Description:
This VI could be used to keep a user from interfering with a process taking place. While the VI is running, the user would not be able to use the mouse nor the keyboard and the mouse cursor would be set to busy to indicate that something is in process.
3. Requirements
4. Steps to Implement or Execute Code
5. Additional Information or References
WARNING: This code if not used properly will remove user control from your computer. You must re-enable user input after blocking it!!
VI Snippet
**This document has been updated to meet the current required format for the NI Code Exchange.**
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
Hi, Dustin
Thanks for posting.
This is a good example of calling into the user32.dll from LabVIEW. The main drawback (as indicated by your warning) is that your example blocks access to the entire system. Blocking user input to the entire system may be desirable if performing operations that affect the entire system (such as software installation); however, I believe that in most instances users would desire only to prevent the user from interacting with VI front panels. This behavior can be achieved by using the Show Busy Indicator function that I contributed to the community a while ago.
The key difference is that the Show Busy Indicator function does NOT block user input to the entire system -- only to LabVIEW front panels. Additionally, the Show Busy Indicator function provides a visual indication to the user that alerts them that user input is blocked.
As with your example, you must ensure that you use the Show Busy Indicator function properly. If you forget to "turn off" the busy indicator, you will be completely blocked out of LabVIEW -- but this is typically only an issue in development. Additionally, even if the user does happen to do this, the effect is much less severe since the user is only blocked from accessing LabVIEW front panels vs. being completely blocked from the entire system.
Also, I did notice that it is possible to use the Ctrl+Alt+Del key combination while the input is supposed to be blocked -- possibly allowing the user to shut down the system or terminate processes when they shouldn't be able to.
One last note: I do have to state that I adapted the Show Busy Indicator function from a VI that I discovered while using TestStand 1.0 (that fact is noted in the community post and also in the VI help for the Show Busy Indicator function).
Again, thanks for posting this example.
Mark Ridgley
These functions require running Labview as an administrator (at least in Windows 7).
Function Documentation Link:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646290(v=vs.85).aspx
Thank you for posting this example.
I noticed that this example also blocks virtual keyboard entries.
In my application, I would like to block physical keyboard entries while I am sending virtual keyboard entries to a different Microsoft program. I want to prevent the user from accidentally interfering with the sequence of virtual actions. How would I implement this?
Peter Buerki