Archive: Unexpected $PLUGINSDIR directory launch


Unexpected $PLUGINSDIR directory launch
At the end of my installer script, I am using ExecShell to open a file downloaded to the $PLUGINSDIR with:
ExecShell "open" '"$PLUGINSDIR\${FILENAME}.mov"'


Try just:
ExecShell "open" "$PLUGINSDIR\${FILENAME}.mov"

What is ${FILENAME} at that time (check with a MessageBox for example).

-Stu


Ok, I think I finally narrowed it down...
;
If I disable every occurence of 'setoutpath' execept for the mySpash Function below, the unexpected directory launch is the last setoutpath command in the function...$DESKTOP in this case.
;
If I disable ALL setoutpath commands, the project directory [where the exe is compiled] unexpectedly launches...
Is there a way to suppress these directory launches ?
strange bug...
;
Function mySplash
InitPluginsDir
SetOutPath "$PLUGINSDIR"
File /oname=$PLUGINSDIR\splash.bmp "${FILENAME}.bmp"
advsplash::show 1500 600 400 0xFFFFFF $PLUGINSDIR\splash.bmp
Pop $0
Delete $PLUGINSDIR\splash.bmp
SetOutPath "$DESKTOP"
FunctionEnd


Could you attach your script?

-Stu


it is a bit long, but the main function that seems to be causing/controlling the directory launch is mySplash..
Editing the setoutpath location on the last line of the function will control which directory launches.
;
if I disable the mySplash function, then the directory of the compiled exe launches
;
Also, the directory launch only occurs on a full install located in 'Section "FullInstall" SecDummy'


I noticed this:
Function InstallQuickTimeFromDVD
ExecWait '"$qtInstallerLoc"'
FunctionEnd
Could this be it?

Edit: Nevermind, that's a website URL.

-Stu


I noticed that you're using a s**t load of variables. These can take up a lot of memory on run time, and a lot of them could easily have been used as !define's instead (which are only used on compile-time.)

The only thing that could possibly be causing this is the double quotes on all the exec's (e.g. '"file.ext"'. This isn't necessary. Try changing them all.

-Stu


thanks Afrow :)
I'll give it a try
thanks for taking a look
yes, the variables got a bit out of control on this project
If I use this one as a shell for another project, I'll be slashing and burning as far as variables go
g


changed all exec commands to :
ExecWait '$R0'
or
ExecShell 'open' '$R0'

is there anything else that could be causing the directory launch


I couldn't find anything. Could you make a cut down version of your script which we can test that produces the problem. We can't test the current one because we don't have the files and stuff to go with it.

-Stu


thanks Afrow :)
let me see what I can come up with
might be better for me to zip the whole project which is fairly small as all the major stuff is downloaded from the server
I'll include the extra plugins too...
and give a link to the .zip'd project


Yeh that will work also :)

-Stu


Hi Afrow :)
I sent you a private message with a project link
thanks for taking a look as I am very stumped

g


You mean e-mail or on here... I haven't got any new PM's.
I'm currently at college (no NSIS compiler here!) I'll be getting home about 7GMT tonight so I'll take a good look then.

-Stu


yes, I sent you a priave email on this discussion board
I'll send you another one just in case.
;
what are you studying ? College for me was about 10 years ago...Got so burned out after graduation, I could not enjoy reading books for 1 year. Kind of sad.
g


Pure maths, business, accounting and computing.

So when is the directory actually launched?

There's a lot of warnings after compile. You might want to check them all out.

-Stu


;Pure math
Differential equations and such ?
I got a Finance Economics BS...and then became a professional composer for TV commercials..strange paths
at least, my degree made me lose my fear of numbers for writing budgets.
;
I checked the warnings out. At first glance, it seems none of them would cause a window launch. Most of them are from the writeXML.nsh file which is a bit older and needs house cleaning. I removed the writeXML.nsh to see if its functions were causing the problem. Directory still launches :(
;
The directory launches ONLY on a Full Install where the 3rd party installer QuickTimeInstaller.exe is executed. On the final ExecShell:
ExecShell 'open' '$PLUGINSDIR\${FILENAME}.mov' on line 437 in the function 'FullInstall' in the .nsi file, the window launches...Wierd
;
g


What happens if the ExecShell line is commented out?

-Stu


the directory still launches :(
;
If I disable the launch of the 3rd party installer, , ExecWait '$PLUGINSDIR\QuickTimeFullInstaller.exe' $0
the directory does NOT launch.
;
Strangely, the 3rd Party Installer is not asking for a SPECIFIC directory launch as the last setoupath command controls which directory pops up
;
is there some system call that would supress the launch ?
g


SetOutPath will be setting the working directory for QuickTimeFullInstaller.exe
Try placing SetOutPath "" before the ExecWait instruction.

-Stu


If I clear the Working Directory,the $EXEDIR directory pops up.
Seems like the option at this point is to redesign the 3rd party installer and combine it with my NSIS installer :( I guess it is too much for a billion dollar company to make a decent installer package. In my experience, Apple is pretty consistently at war with its own developers.
;
Is there some way to 'listen' for a directory launch call and squash it before it executes? Maybe, a system command can save the day. Otherwise, I'll have to open up another can of worms.
;
thanks for walking me thru the debug,Afrow :)
g


What about setting the working dir to a folder that doesnt exist or a invalid directory name? (Not sure if SetOutPath catches this, if it does u could call the raw api)


will try the above :)
Also, the directory only launches in Win2000 and 98
For XP, everything works just fine..
weird
g


I setoutpath'd to "blah\blah\nonextistent"
seems the command was ignored
;
strangely, when I setoutpath to the above, the installer waited an extra 2 seconds before it launched the directory
maybe it was thinking ;)
;
At this point, if faced with this kind of thing, would you guys create your own distribution of a major piece of software? Wonder if there are any legalities lurking there ? Or, would you roll with bug and use the opened directory to house a ReadMe file and some goodies...
g


Don't forget that SetOutPath will recursively create the path that you give it, so giving it a bad path might confuse it! Or it will create the directory path in the root.

Sounds like it's the QuickTimeFullInstaller.exe at fault here. What if you make it run another executable... does a folder still open?

-Stu


I narrowed it down to ANOTHER executable ,QTPluginInstaller.exe, called WITHIN QuicktimeFullInstaller.exe.
;
As long as QTPluginInstaller.exe is run, the working directory will launch. Thankfully, the problem is only for 2000/98 and does not happen on XP.
;
If I can't get a response from Apple/QuickTime a week after this week's holiday, I'll redesign the installer. Sometimes Apple responds quickly, and sometimes they do not respond at all despite repeated attempts.
;
Thankfully, I have an exe that converts reg values to a nsis script...so it should not be too hard. Lots of files and reg values...
;
Maybe this is a good thing....
Executing 3rd party installer within a main installer is kind of kludgy anyway and looks a bit ugly.
g