Pradeep wrote:
> My example of notepad.exe was just to demonstrate the bug. I see the same
> behavior even due to a native install which is not an interactive program.
> Moreover I need to pass execution parameters to the native install.
> Therefore I use:
>
> args = "/arg1 a /arg2 b"
> execute("nativeInstall.exe", args);
>
> The XPInstall API guide also documents the second parameter in the execute
> to be arguments to the executable and the behavior I see with the above
> usage is appropriate.
>
> execute("nativeInstall.exe", true);
>
> I do not know of the blocking argument you have mentioned. Do I need to
> modify the native executable to do something different using an additional
> parameter ? Or is this a parameter for Mozilla. Pls. let me know. I would
> prefer to go the blocking route as advised.
The optional blocking argument was added to both documented forms of
execute() somewhere around 0.9 or 0.9.1. If you need arguments then
execute("nativeInstall.exe", args, true);
would work perfectly fine.
> Also do I need to return any specific return code from nativeInstall.exe ?
In the non-blocking case the return value is unimportant; I'd have to dig a
bit to see if it matters in the blocking case, but it'd be safest to return
0 rather than some error code.
> Is there a way to wait for it to finish after performInstall like a thread
> sleep ?
The blocking option described above
> Alternatively is there a way to clean up the temp file myself in the
> web page after the install using JS api so the message doesn't pop up?
No, you'd have difficulty guessing the temp file name in a reliable way, and
besides unsigned javascript on a webpage doesn't have the ability to touch
files on a user's system anyway.
-Dan Veditz
