Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#684 closed Feature Request (Rejected)

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

Reported by: Hubertus Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: ShellExecute return ProcessId Cc: Hubertus.Endres@…


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)

Attachments (0)

Change History (5)

comment:1 Changed 15 years ago by TicketCleanup

  • Version deleted

Automatic ticket cleanup.

comment:2 Changed 15 years ago by Valik

  • Resolution set to Rejected
  • Status changed from new to closed

The PID is not available to be returned.

comment:3 Changed 15 years ago by Ascend4nt

The PID is indeed available to be returned as a parameter. Check the UDF here:

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,

comment:4 Changed 15 years ago by 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.

comment:5 Changed 15 years ago by 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).


Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.