ShellExecute() should return ProcessId instead of 1 if all is OK.

[Hubertus]

It would be easier to control the spawned process if the Pid is available.
For compatibility reasons, you should introduce a sixth Parameter named showpid with the default of 0=no (return 1)

[TicketCleanup]

Automatic ticket cleanup.

[Valik]

The PID is not available to be returned.

[Ascend4nt]

The PID is indeed available to be returned as a parameter. Check the UDF here: ​http://www.autoitscript.com/forum/index.php?s=&showtopic=93057&view=findpost&p=668805.

Since ShellExecuteEX() returns the Process Handle, it's a simple means to get the Process ID. I believe this should definitely be incorporated into the function. Even returning the Process ID in @extended would be cool. Or alternatively, leaving the Process Handle open and returning that - but this would rely on the coder closing the process handle.

This is actually leads to a main grudge I have about 'ShellExecuteWait()' - it doesn't allow a timeout, plus the simple call itself will add 8MB+ to the resident 'WorkingSet' memory. (after a call to the popular '_ReduceMemory()' UDF). This is why I prefer to make the ShellExecuteEx call, then call '_ReduceMEmory()' to reduce the WorkingSet while waiting for some application to finish running - a great way to open up memory to that process and keep the program from looking bloated.

Please revisit this matter. Thanks,
Ascend4nt

[Valik]

Have you actually read MSDN on the matter? It's pretty clear from MSDN that ShellExecuteEx() does not guarantee a process handle will be returned. I'm not interested in adding a confusing feature that takes two paragraphs to explain the limitations.

[Ascend4nt]

I've read it, and the result was my function. Try taking a look at it. And yeah, sometimes you can, sometimes you can't get the Process Handle and/or PID, but you already have ShellExecuteWait() which obviously has the same limitations, so why is it such a big deal to add this relatively small addition? If you can't get the PID, (and you choose to return the PID in @extended), simply return with @extended = 0. No harm, no foul.

If the issue is how confusing it is to the user, that really doesn't make sense since ShellExecuteWait() will not actually 'wait' for certain things to close either, meaning a Proces Handle or PID was probably not returned (or was terminated in the case of, for example, opening an explorer window - which starts explorer, then terminates it and hands over the processing to the already-running explorer process).

Ascend4nt