Auto-run the installed app

Hello all,
I'm having a slight problem with the end of my installer. I have been asked to make the program we are installing auto run once the installation has finished.

At the minute I have a dummy section which ends thus:

; Pop up dialog to kill the movie player when the downlaod is done. 

HideWindow MessageBox MB_OK "Your Learn To Play Experiance is now ready. Press OK to begin." 

sleep 500 

FindWindow $dialogeHWND "#32770" "" $HWNDPARENT 

DetailPrint $dialogeHWND 

Call repositionDialoge 

KillProcDLL::KillProc "projector.exe" 

; Run the program 

ExecShell open "LTP\Program.exe" 

sleep 1000 

Delete Install.ini 

Delete LTP_Movie.exe 

SectionEnd

However my program is shutting itself down straight away. I have a feeling this is to do with the way I am running the program from the installs as if I navigate to the install path and run it from there it runs fine.

Any help would be greatly appreciated

SetOutPath will set the working directory, so you should probably set it to the LTP folder. Also, you should specify the full path to the exe in ExecShell (Just plain Exec is fine for .exe files, no need to use ExecShell)

The output path has been set at the beginning of the script.
however I shall quickly try this and see.

*Edit*
Nope no luck using

Exec '"$OUTDIR\LTP\XylophoneP.exe"'

After some investigation it appears as though my exe is being moved away from its data which causes the file to auto exit.
So my next question is does either exec or execshell move the application

of course it does not move the file

Well the executable is sat right next to my data folder, the executable runs when I run it manually. I've debugged my application and when run from the installer it cannot find a required file in the data folder. So it seems the logical explanations are that either the application has been moved, the wrong application is being run or the data has moved.

wrong working / current directory?

Everything extracts to the correct dir which is $OUTDIR\LTP
and the documentation states that exec and execshell both use the current $OUTDIR as their working directory. so i don't think so. I've gotten around the problem for the moment by using:
ExecShell open LTP\Short
which is a shortcut to the file and that runs it correctly. however I would like to get to the real issue and not have to use the shortcut

check with process explorer to see the working directory. And process monitor or filemon to see which directory your application is looking in

Process Monitor reports that it is looking in the same folder as the installer is located in.
However the application should only look in the folder it resides in.
Process Explorer is reporting that it has been executed from LTP\ so Im still at a bit of a dead end

Just to keep the thread updated so please excuse the double post.
On a whim I added the following lines

SetOutPath $EXEDIR\LTP

; Run the program

ExecShell open Program.exe

the EXEDIR is there purely for debug purposes btw.

And it now works... yay.

my next question is can I use syntax like

SetOutPath $OUTDIR\LTP

if so I think that will solve my problem well enough

You say it's been executed from LTP\ And you say you don't want that so why are you still talking about SetOutPath $OUTDIR\LTP??

If you install the .exe to $instdir\myapp.exe, all you need is SetOutPath $instdir

I didn't say I didn't want it run from the \LTP folder.
I set the outdir to $exedir\LTP as an experiment to see if it for some unknown reason effected the directory my program was using as its root. And I set the root to $EXEDIR as other files are used in that root and then the application itself and its data is extracted to .\LTP

I'm just more curious as to why the SetOutPath function affects the root of my application.

because setoutpath changes the current aka working directory, a child process will inherit this working folder unless you specify a new working folder when calling CreateProcess (so, the nsis way to specify it is to use setoutpath before calling Exec)

Ah that makes sense now then.
Thank you for your help