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.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
