LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to Run System Exec (Batch File) as an Admin

Solved!
Go to solution

@parthabe wrote:

 

 


@RTSLVU wrote:


but you also lost functionality of any third party or purchased NI 32bit tool kits.


How?!


32bit LabVIEW toolkits and third party add-ons do not work with 64bit LabVIEW.

 

You will need to purchase the 64bit version of any toolkits or third party add-ons.

 

IF they even exist.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 11 of 16
(2,641 Views)

Thanks for the tip on how to use Shell32 to run with elevated privileges.  I have a follow-up question:

 

Do all Windows computers have Shell32.dll?  And is it always in C:\Windows\system32?

 

I am asking because I am going to deploy my VI to numerous other Windows computers, and I am worried that they might not have Shell32?  Any tips on how to modify your snippet so it is deployable to any Windows computer?

 

Thanks, John

http://www.medicollector.com
0 Kudos
Message 12 of 16
(2,323 Views)

@josborne wrote:

 

Do all Windows computers have Shell32.dll?  And is it always in C:\Windows\system32?


Answer to your first question - looks like, yes! Mine is a Win10 Pro 64-bit OS, and it has this DLL present in the location you have mentioned.

Answer to your second question - By virtue of the above, yes!

- Partha ( CLD until Oct 2024 🙂 )
0 Kudos
Message 13 of 16
(2,315 Views)

More correctly though, for a 32 bit application the shell32.dll that it will attempt to load is in SysWOW64. But you should anyhow only enter the DLL name itself without any directory and that way Windows will resolve to the system directory that matches your architecture. And yes system administrators are able to set the directory to which Windows gets installed to something else than C:\Windows, for instance useful for thin clients.

Rolf Kalbermatter
My Blog
Message 14 of 16
(2,310 Views)

I'm on LabVIEW 2019 SP1 (32-bit) and I don't want to go to 64-bit right now so I'm using Shell32.dll.

 

Is there a way to make Shell32.dll

  1. Wait until the batch file is executed.
  2. Get the standard output and standard error output of the batch script.
  3. Hide the command line window (not priority).

 

Edit: Hiding the window can be accomplished by setting the nShowCmd input to 0 instead of 1.

0 Kudos
Message 15 of 16
(1,867 Views)

@JonathanMATech wrote:

I'm on LabVIEW 2019 SP1 (32-bit) and I don't want to go to 64-bit right now so I'm using Shell32.dll.

 

Is there a way to make Shell32.dll

  1. Wait until the batch file is executed.
  2. Get the standard output and standard error output of the batch script.
  3. Hide the command line window (not priority).

 

Edit: Hiding the window can be accomplished by setting the nShowCmd input to 0 instead of 1.


Not without some serious programming of your own. The ShellExecute() function is a convinience function that was added to Windows way back to simplify process creation. When the heightened security was added, ShellExecute() also learned the runas verb to invoke the launched process under different user credentials than the current user. There is a ShellExecuteEx function that also returns the Handle of the created process (but not always, depending on several factors). You could use that handle to monitor the process state and only continue after the process handle signals that the process has terminated. You could likely also retrieve the stderr and stdout from that process handle with more WinAPI calls but I haven't checked how that would work. So even with that it would be not a sure way to work.

 

The alternative to go through the lower level Windows API CreateProcess() allows to monitor the state of the process very well and also hook the stderr and stdout handles to get all the data but there is no way I'm aware off to cause an elevation dialog for the process on that level, since the whole elevation seems to be rather something implemented in the Windows shell rather than the kernel.

 

But any of this is not specifically something you ever want to do all in LabVIEW. It is serious C programming that is much better done in an external DLL and then called from LabVIEW.

Rolf Kalbermatter
My Blog
Message 16 of 16
(1,842 Views)