[sword-devel] BibleCS Installer

[DM Smith]

L.Allan-pbio wrote:
>>> * 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?".
If the application owns it then the uninstaller should remove it. I'll 
look into it some more.
>
>> 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."
No need to be apologetic. This is a good time to have the fundamentals 
in place even if we cannot have an ultimate solution.

I think this is fairly easy, but I could be wrong.
If after
DeleteRegKey              HKLM SOFTWARE/CrossWire/The SWORD Project
DeleteRegKey /ifempty HKLM SOFTWARE/CrossWire
the key SOFTWARE/CrossWire still exists then there are more than one 
apps present.

Of course, it is complicated by being present in either HKLM or HKCU, 
but the principle is the same.
>
>
>> 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'm not against having them. But I'd rather not replace a page that MUI 
provides merely because I don't like its implementation.

By having them, we sign up to the responsibility for internationalizing 
those pages, should the need arise.

I see that we are going to have at least two of them.
One will be the pick of whether the user wants HKCU or HKLM.
The other will be a pick list of additional shortcuts (e.g. Desktop, 
QuickLaunch, perhaps others)
>
> 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.
.onGUIend is in the manual and says the following:


          4.7.2.1.5 .onGUIEnd

This callback is called right after the installer window closes. Use it 
to free any user interface related plug-ins if needed.


>
> 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)?
Yeah, it *is* version dependent.
Whether the code is called needs to be dependent on whether the user has 
chosen to run the program from the installer.
(I almost always say no. Same to readme.)
>
> I'll take a look at a custom page with the 2 radio buttons you 
> described .... tying them to HKLM and HKCU issues. 
Thanks.
Another issue. The user may do a HKCU install and then re-run the 
application with a HKLM install. A later install should migrate the keys 
(i.e. delete and add)
> Have you tried out and looked into the code for the LcdBible prototype 
> installer with custom page for installation choices?
Yep and I gave you feedback. I also looked into the code for the 
installation choices, too.
The place where I see having installation choices for BibleCS is on a 
page of shortcuts. Probably two checkboxes on a single page, not a tree 
of components.