How does one detect whether the app was previously installed and offer to
uninstall first prior to new install?
~~~~~~~~~~~~~~~~~~~
Sim Sherer
Printable View
How does one detect whether the app was previously installed and offer to
uninstall first prior to new install?
~~~~~~~~~~~~~~~~~~~
Sim Sherer
Hi Sim,
I don't think Friedrich has a specific function for this but it
wouldn't surprise me :)
What I normally do is on the initial installation I get SB5 to write a
registry entry that notes the installation directory. All subsequent
installations/updates can read this registry value. This serves to
firstly confirm that the application has been previously installed and
secondly where to.
I don't offer to uninstall but if I were, I could easily use the
registry entry to tell me where the application resides and therefore
where the uninstaller resides. I then just have to RUN it. I don't
know whether you can include a RUN Parameter to make the uninstall
silent, but if not it would be easy to do something like this:
Get your installer to write an entry to an ini file before RUNning the
uninstaller. You would have designed your uninstaller such that it
would be set up to read the value of that ini file to determine if it
was to be a silent uninstall or a normal uninstall.
There's probably a number of ways to do this given the power of SB5
but the above would work just fine.
Best Regards,
Geoff Spillane
Data Down Under
>How does one detect whether the app was previously installed and offer to
>uninstall first prior to new install?
Sim,
What Geoff said. SB's Run Program does have a Wait for Program option. Here's
some other things that come to mind.
Developer Edition has a Detect Previous Version script item that sets a
variable to the path to the previous version, if detected. With that you can
execute your uninstall like so: PathToYourUninstall.exe /U
"PathToYourUninstall.log". Be sure to quote the install log path if it
contains spaces.
Search for File in the Developer Edition is an alternative to Detect Previous
Version. You could use it to search for your exe and/or your uninstall
program, executing the uninstall after verifying the log file exists.
If you have to be sure the uninstall completed successfully, SB's Run Program
sets % SB ERRORCODE% to zero on success. I don't know if that's an indication
of successful execution by the OS, or an exit value from the run process. It
would be easy enough to verify the program no longer exists, if needed.
Using either of those methods to detect the program's existence, you could
simply display a message asking the user to uninstall the previous release,
and then exit the script.
--
Best regards,
Mark
-------------------------------------------------------------------
Why waste time learning when ignorance is instantaneous?
We do email right!
Rock solid hosting services at http://www.lanbytes.net
Hi Mark,
I had found that on occasions the wait flag for the RUN function
didn't do the trick, particularly when the EXE launched is a
windowless process, so Friedrich showed me a clever way of using the
power of the scripting language to make sure a process had indeed
finished. In the code below I launch the Windows media player
installer in silent mode then set up a loop to periodically look to
see if the installation has completed. If it gets to Loop 4 then it
breaks the loop with a message saying the uninstall failed. The full
list of Return codes for the RUN function follows.
Run Program %_SB_INSTALLDIR%\wmpcdcs8.exe (Always Install)
Set Variable %LOOPID% to 1
Loop
Set Variable %LOOPID% to (Increment variable by 1)
Pause for "3" seconds
Set Variable %ACTIVE% to Detect Active Application(wmpcdcs8.exe)
If %ACTIVE% Equals "0" Or %ACTIVE% Equals "603" Then
Break Loop
End
If %LOOPID% Equals "4" Then
Message Box "The uninstall failed.........."
Break Loop
End
End
// Return codes are as follows:
// 0 = Process was successfully terminated (Process was not found)
// 1 = Process was found
// 603 = Process was not currently running
// 604 = No permission to terminate process
// 605 = Unable to load PSAPI.DLL
// 602 = Unable to terminate process for some other reason
// 606 = Unable to identify system type
// 607 = Unsupported OS
// 632 = Invalid process name
// 700 = Unable to get procedure address from PSAPI.DLL
// 701 = Unable to get process list, EnumProcesses failed
// 702 = Unable to load KERNEL32.DLL
// 703 = Unable to get procedure address from KERNEL32.DLL
// 704 = CreateToolhelp32Snapshot failed
Best Regards,
Geoff Spillane
Very interesting, Geoff. Thanks. Where did the run return codes come from?
--
Best regards,
Mark
-------------------------------------------------------------------
Why waste time learning when ignorance is instantaneous?
We do email right!
Rock solid hosting services at http://www.lanbytes.net
Hi Mark,
To be quite honest I don't know. When Friedrich first gave me some
example code it didn't give the correct results so I monitored the
return value and told Friedrich my observations and he came back with
confirmation of what I had found plus what the errorcode meant
together with the list of all the other possible values. I had
presumed that they were the return values from the API he used (which
I thought I knew) but I can't find them in the SDK.
Best Regards,
Geoff Spillane
Data Down Under
Mark,
Open the "Detect Active Application" script item dialog and press F1 to
display the help ;-)
Friedrich
--
Friedrich Linder
CEO, Lindersoft
www.lindersoft.com
1.954.252.3910