[sword-devel] BibleCS Installer

[L.Allan-pbio]

>> * HKLM SOFTWARE\Classes\sword ???
>>   Seems to be set by running sword.exe .... whole series of registry 
>> entries. Perhaps these should be removed also?
> These are being created by the OS. Not by the installer or the executable.
>
> Try installing and running 1.5.6 and then search for registry entries. 
> There are a bunch that are managed under some notion of shared library. In 
> looking at where these extra entries show up, I also see a bunch for stuff 
> that I have uninstalled from other applications.

The InstallShield uninstaller removes them .... with a confirmation about 
"this is the last application to use these .... ok to delete?".

> I think that the installer and uninstaller should be responsible only for 
> the entries that are directly managed by by the installer and the 
> application. As far as I know, the application doesn't do anything with 
> writing registry keys.

I speculate that a BCB app has a default/standard practice of writing a 
registry entry during InitInstance or OnInit. I think a case can be made 
both ways on whether the uninstaller should remove HKLM 
SOFTWARE\Classes\sword

> I didn't think about overwriting. I'll see about adding a check to see if 
> it is currently defined and pointing to an existing directory. If it is 
> not then I think it should be set.
>
> This should be in a separate nsh file so all SWORD family applications can 
> use it.

I'm interested in seeing what you come up with.

>> * Uninstaller may not want to remove SWORD_PATH environment variable. 
>> Leave it around for other "sword-api family apps" to make use of.
>>
>> * May not want to get rid of mods.d and leave it for other "family apps" 
>> that are making use of SWORD_PATH. I think the InstallManager.exe is the 
>> appropriate way to get rid of mods.d files (to keep them sync'ed ok with 
>> contents of subdirectory modules?)
> I think that there should be a dialog asking the user whether the sword 
> modules should be removed, if this is the last application in the SWORD 
> family to be removed. If the answer is yes then the modules and env var 
> are removed. Otherwise they are left intact.
>
> This will be part of the final solution. OK?

Lots can go wrong here .... glad you are involved. The uninstaller issues 
were most of my concern about actually being responsible for the installer 
.... glad to help, but reluctant to actually be the "guilty party."

> This should be in a separate nsh file so all SWORD family applications can 
> use it.
>>
>> * Baffled by what is happening in the SwordUtil::AllDone function to read 
>> Field 4 and Field 5 of ioSpecial.ini. I only see 3 fields in 
>> ioSpecial.ini
> Its baffling because it relies upon the actual execution of what should be 
> "black box" code.
>
> I studied the code in NSIS/contrib/Modern UI/system.nsh
> It uses the ioSpecial.ini (which has only the 3 fields as you noted) as a 
> starting point.
> This file is copied to $NSISPLUGINDIR (generally in temp) and then 
> manipulated by the various MUI macros.
> The check boxes on the Finish page can either be reboot or it can have 
> one, the other or both of "run" and "readme".
> Based upon this Field 4 is for reboot, and if reboot is not specified, 
> then run and if run is not specified then readme.
> If run and readme are specified then these become fields 4 and 5 
> respectively.
>
> Now if the MUI changes, then all bets are off. These could be fields 6 and 
> 10. Or have meaningful names.
> I should probably put a check in against MUI_VERSION and abort the compile 
> if it is otherwise.
>
> What the AllDone done is called after the user (un)checks the RUN and 
> README options and then clicks on "Finish" (I think that's the button 
> label)
>
> So at this time, the MUI code is checking for Field 4 and 5. It then 
> sequentially runs the RUN action followed by the README action.
> The run action is executed using Exec, which is non-blocking or Call, in 
> the case of a function.
> The readme action is executed using ExecShell on "open", which is 
> non-blocking or Call, in the case of the function.
>
> So I created a function AllDone that is called by both the RUN and README 
> callbacks. This function is a run once.
>
> Since ExecShell is non-blocking, I changed the execution of the readme to 
> explicitly use notepad and to use ExecWait. The significant difference 
> here is that if the user has set emacs, vim or some other text editor as 
> their default *.txt open action, it will not be used. And it now waits 
> until the user is done.
>
> If the user chose to run the application, I bring up the installmgr and 
> then the application. (using the code you supplied)

I looked a bit closer ... I am ending up with a modified ioSpecial.ini in 
the root directory of C:\  ... not the TEMP directory

If you incorporate a Components page (which you haven't so far), then you 
can control having the readme.txt shown independently and before the 
InstallManager.  The .onInstSuccess standard function seems to be called at 
the same time as the FinishPage, so I wasn't able to get one showing before 
the other.

Are you against have a Components page, or is it more a matter of avoiding 
that unless absolutely necessary and there is no other way to do something? 
The Components page does give you nice control over sequencing.

I'll look on the .onGUIEnd standard function ... perhaps a place to show 
readme.txt
hmmmmm.
.OnGUIEnd appears to be the very last function called .... after anything on 
the FinishPage and after .onInstSuccess. The MUI doc has discussion about 
appending your own .onGUIInit code, but not .onGUIEnd. I'll put in a 
question to the nsis forum to check if there is supposed to be any "hook" 
for .onGUIEND that wasn't mentioned in the documentation, or whether an 
installer is free to use it "unencumbered" .... For now, it looks ok to use.

Perhaps a function for .onGUIEnd could have:
ExecWait '$INSTDIR\InstallManager.exe'
Exec '$INSTDIR\sword.exe'

and avoid the tricky stuff with ioSpecial.ini (that may be MUI version 
dependent)?

I'll take a look at a custom page with the 2 radio buttons you described 
.... tying them to HKLM and HKCU issues. Have you tried out and looked into 
the code for the LcdBible prototype installer with custom page for 
installation choices?