Current Folder Bug?

[petersa]

Hi guys,

I think I might've uncovered a bug here.

The following code doesn't work:

code:
!PackHdr TEMP.DAT "UPX.EXE --best TEMP.DAT"

OutFile PD.exe

SilentInstall Silent

CRCCheck On



Section ""

  SetOutPath "$TEMP\SETUP.PD"

  File AUTOMATE.EXE

  File PATCH.EXE

  File SETUP.EXE

  ExecWait "AUTOMATE.EXE"

  RMDir /R "$TEMP\SETUP.PD"

SectionEnd

When I run the compiled setup, it extracts the files to $TEMP\SETUP.PD, and seems to not run AUTOMATE.EXE. However, this works:

code:
!PackHdr TEMP.DAT "UPX.EXE --best TEMP.DAT"

OutFile PD.exe

SilentInstall Silent

CRCCheck On



Section ""

  SetOutPath "$TEMP\SETUP.PD"

  File AUTOMATE.EXE

  File PATCH.EXE

  File SETUP.EXE

  ExecWait "$TEMP\SETUP.PD\AUTOMATE.EXE"

  RMDir /R "$TEMP\SETUP.PD"

SectionEnd

But the first piece of code should work though, because Exec and ExecWait set the working directory, which is in this case, $TEMP\SETUP.PD.

I'd be happy with the second piece of code, but something's wrong if I have to specify $TEMP\SETUP.PD\ on the ExecWait command, and I need to have the current directory set to that or hell will break loose.

Hope I haven't lost too many people here.

Anyone?

[Edgewize]

I came across this one, too ... the current working directory is never changed, AFAIK, regardless of how many SetOutPaths you use.

I just rewrote my program to take the directory as an argument :/

[yazno]

hi,

i tested it and came to the same conclusion: a bug in Exec and ExecWait.

the $OUTDIR is not used as working directory as promised in the documentation.

BUT .. i tried it with ExecShell and there it works fine.

cu yzo

[petersa]

Well, I can't use ExecShell, because I need to make sure that AUTOMATE.EXE has finished before removing the folder.

I could change AUTOMATE.EXE, but since I have 7 or 8 of these, it'll take a while to edit their sources and recompile them all...

I think I'll wait for the bug fix.

[yazno]

hi,

you could do it with execshell and popup a messagebox which says: 'click ok when automate.exe finished' or use sleep.

i know both are just dirty workarounds and for sure, the best is to wait for a bugfix

cu yzo

[petersa]

I'd like to but AUTOMATE.EXE, for the most part, is silent so you can't pinpoint when it's finished, or at least the user wouldn't be able to...and since there are also waits for user input, that wouldn't work either...

Thanks anyway, yzo!

[yazno]

hi,

LOL - i don't wanna bother you, but i have a run now and one last solution until the new version comes out .. hehe.

use execshell, then create a loop and check with findwindow(bytitle) if automate.exe is running

cu yzo

[petersa]

Not a bad idea!