02-22-2023 09:08 AM
Hello All,
We're working in an environment where all users will now require unique windows accounts rather than a shared "public," account. However, this is creating an issue where.
Is there a way to efficiently (in order of preference):
02-22-2023 09:27 AM
This is tricky, logically, the best way to implement is to auto-shutdown the application on user logout instead of some other user telling it to shut down.
I feel another user should not have control over what you run on your windows login. Why can't the application run multiple instances? does it use the same hardware resource causing an issue?
02-22-2023 09:44 AM
@santo_13 wrote:
I feel another user should not have control over what you run on your windows login. Why can't the application run multiple instances? does it use the same hardware resource causing an issue?
Correct.
The application runs test hardware that will only allow one connection at a time.
02-22-2023 10:18 AM
Usually when you log out, all applications will be terminated. You can't leave LabVIEW running unless it's a service.
If you make your LabVIEW program run as a service, then all user should be able to get data/status from it.
02-22-2023 10:20 AM
@zou wrote:
Usually when you log out, all applications will be terminated. You can't leave LabVIEW running unless it's a service.
If you make your LabVIEW program run as a service, then all user should be able to get data/status from it.
I think they must doing "switch user". In that case, all tasks for that user are suspended while the other user is logged in.
02-22-2023 10:23 AM
@zou wrote:
Usually when you log out, all applications will be terminated. You can't leave LabVIEW running unless it's a service.
For us, we have a "Switch user" option in our logout menu. If a user idles for too long, a login screen appears and another user can log in as if this option was selected.
02-22-2023 10:29 AM
@JScherer wrote:Is there a way to efficiently (in order of preference):
- "Link," the LabVIEW.exe across all users so that the exe maintains state and is universally available to all users.
- Have User B's start of LabVIEW.exe send an event (over TCP?) that will disconnect and close User A's instance of the software.
- Have User B's start of LabVIEW.exe force close all other instances of LabVIEW.exe as can be done via task manager.
To clarify, you are talking about a LabVIEW application right? LabVIEW.exe is the LabVIEW development environment itself, whereas "a LabVIEW exe" typically means any application built in LabVIEW. The options make it sound like User B is opening the LabVIEW development environment. Is that what you meant?
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
02-22-2023 10:30 AM
Switch user is different from logout.
Again, you can use service to solve the problem.
https://lavag.org/topic/19286-running-labview-executable-as-a-windows-service/
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000004AUiSAM&l=en-US
02-22-2023 10:31 AM
@JScherer wrote:
@zou wrote:
Usually when you log out, all applications will be terminated. You can't leave LabVIEW running unless it's a service.
For us, we have a "Switch user" option in our logout menu. If a user idles for too long, a login screen appears and another user can log in as if this option was selected.
Yes, that is what I figured. AFAIK, if you have admin privileges, you can kill the task or kill the user. Well, not literally - although sometimes when this happens the thought crosses your mind.
The best way is to adopt a policy that prevents this from happening. (Good luck with that!)
02-22-2023 10:59 AM
> Have User B's start of LabVIEW.exe send an event (over TCP?) that will disconnect and close User A's instance of the software.
This option is a lot easier.
Everyone should use a "launcher" instead of the original application.
If launcher detects the application is running, it should close the application before launch another instance.
You can use TCP, Shared Variable, or other methods to notify the application to close "softly".