LabVIEW
SysExec (cmd) : Run as administrator
Solved!
Depends where you see 42! The VI is so programmed that if ShellExecute returns a value smaller or equal to 32, it will return an error 42 in the error cluster and a string "ShellExecute error xx" where xx is a number that is the value returned from the ShellExecute function.
So if ShellExecute returns 42 everything is fine. But if the VI returns error 42 I would like to know the xx value in the error string. And yes 0 return value from ShellExecute would indicate out of memory condition during execution of ShellExecute.
@FermWorks wrote:
How inconsistent to use 0 for an error condition!
That's for historical reasons. In Windows 3.1 the function did return a HINSTANCE value which was a handle that could be used to access the spawned process. Since this value could be almost any possible value the developers reserved the value range from 0 to 32 for some error codes and anything above was a HINSTANCE. Currently the function returns still the error codes range when something goes wrong, but not really a HINSTANCE that could be used to identify the child process. Instead it simply is documented to return a value that is higher than 32 but which can not be used for anything else.
Hi Rolf
Thanks for putting together the VI with the CLFN in it. That's gotten me most of the way to what I was looking for. I need the "wait until complete" functionality and took your advice to start looking into ShellExecuteExA... and I gave up. I might give it a try again later and if I do I'll post my solution.
Thanks again.
I was just about to ask if someone had managed to get ShellExecuteEx to work and then finally remembered struct alignment rules. Here is my attempt at run as administrator and wart for process termination. Probably flawed, but can spawn a cmd.exe as admin and will even time out, so lgtm. Now I'm waiting for Cunningham's Law to take its course.
Yes, this will only work on 64 bit LabVIEW!
Alignment is taken care for properly, but those pointers are now 64-bit integers. That goes well for when you pass them as pointer size integer to a Call Library Node, but there is no way to specify that 64-bit integers in a cluster should be translated to pointer sized integers so they always will be 64-bit and mess up the structure layout for 32-bit execution.
You would have to create two clusters, one for 32-bit and the other for 64-bit and with the right alignment, All Pointers and Handles (H... datatypes) will have to be either 32-bit or 64-bit and the rest stays as is, appropriate alignment bytes added for each. Then use the Conditional Compile structure to call the Call Library Node once with the 32-bit variant, and else with the 64-bit variant of that cluster.
And yes CoInitializeEx() should be redundant. LabVIEW already does that early on during its initialization as it needs that for some interaction with the Windows shell and also ActiveX.
