Callback function .onFileInstalled possible?

Archive: Callback function .onFileInstalled possible?

aportale
16th July 2004 10:34 UTC

Callback function .onFileInstalled possible?
Hi,

before posting a feature request on sourceforge, I want to make sure if my idea could work.

Would it be possible to have a callback function like .onFileInstalled that gets called for each file that was installed?

The name of the last installed file could be in a global variable.

This would make it possible to write a clean Log of the installed files even if
File /r "filetree\*.*"
was used.

That log could be used for an uninstall routine which only deletes the files that were installed by the installer and were not changed afterwards.

-Alessandro

Afrow UK
16th July 2004 11:17 UTC

That may be a good idea, but if it isn't going to be implemented, you could use the Dump log to file function which dumps the install details window text to a selected file.

There is also a More advanced dump log to file function which only logs files containing a selected string (this should help you)

Good luck!

-Stu

aportale
16th July 2004 14:09 UTC

Thanks,

I looked at the dump log functions, and they work well.

It is a nice point to start. Since I would like to also have informations like file size, file date and maybe crc, I would have to parse the dump log and rewrite another log file. But that would be acceptable (for now).

-Alessandro

Joel
16th July 2004 16:01 UTC

Would it be possible to have a callback function like .onFileInstalled that gets called for each file that was installed?

what's wrong with IfFileExists?

aportale
16th July 2004 16:40 UTC

Originally posted by Lobo Lunar
what's wrong with IfFileExists?

This verification would work for single files, but not for:
File /R "manyFiles\*.*"

In don't know the files in "manyFiles\".

-Alessandro

Joel
16th July 2004 18:01 UTC

Display all files and directories?


SetCompressor lzma
XPStyle on

Name "Lobo Lunar"
OutFile "files_in_dir.exe"
BrandingText "Joel Almeida García"
InstallDir "$EXEDIR"
ShowInstDetails show

Section "-default"
DetailPrint "Displaying files and folders in the current dir:"
FindFirst $0 $1 $EXEDIR\*.*
Loop:
StrCmp $1 "" Exit Display
Display:
DetailPrint $1
FindNext $0 $1
Goto Loop
Exit:
FindClose $0
SectionEnd

aportale
16th July 2004 20:18 UTC

Originally posted by Lobo Lunar
Display all files and directories?...

That is surely a good option if You are sure that the directory where You installed You App was empty.
But If You just install a bunch of files into an existing file structure, I cannot track which files were installed by the installer.

Well, I could use Your code before the installation and afterwards, and then look for the differences. But what, if someone else stored some files into that directory during the installation?

-Alessandro

Joel
16th July 2004 20:21 UTC

You can track the number of items, before and after the installation; then now you can compare :)


SetCompressor lzma
XPStyle on

Name "Lobo Lunar"
OutFile "files_in_dir.exe"
BrandingText "Joel Almeida García"
InstallDir "$EXEDIR"
ShowInstDetails show

Section "-default"
DetailPrint "Displaying files and folders in the current dir:"
IntOp $2 $2 + 0
FindFirst $0 $1 $EXEDIR\*.*
Loop:
StrCmp $1 "" Exit Display
Display:
DetailPrint $1
IntOp $2 $2 + 1
FindNext $0 $1
Goto Loop
Exit:
FindClose $0
DetailPrint "Total items in the folder: $2"
SectionEnd

/edit: Update coded ;)

Afrow UK
16th July 2004 20:44 UTC

Originally posted by Afrow UK
That may be a good idea, but if it isn't going to be implemented, you could use the Dump log to file function which dumps the install details window text to a selected file.

There is also a More advanced dump log to file function which only logs files containing a selected string (this should help you)

Good luck!

-Stu

There are various functions on the Archive to do things such as file size (bytes) but obviously you would have to call the function for each file individually on run-time (which would be a bad idea).

There are functions on the archive which recursively search directories for files. You could easily modify one of those functions and strip it down so that it simply creates a list of files in a directory and its sub-folders.

Again though, this is all going to be done on run time, and it could take a while to generate a list depending on how many files were installed, how many sub-folders etc, so I think that the dump log is the best method currently.

-Stu

aportale
16th July 2004 22:49 UTC

Originally posted by Afrow UK
Again though, this is all going to be done on run time, and it could take a while to generate a list depending on how many files were installed, how many sub-folders etc, so I think that the dump log is the best method currently.

Currently, Yes. And I will try to work with it although I am not content.

Operations like file size reading or crc code generation on runtime are a bad idea if I do them all at once, for all the files. I guess the progressbar would stop for a long time, and the user would start the task manager in order to kill the installer.

But with those callbacks I am dreaming of, these operations could be made for each file, after it was written. The installation would then also be slower but the extra calculation would be distributed over the whole time and the progressbar would still be alive.

-Alessandro

Afrow UK
17th July 2004 00:34 UTC

NSIS has CRC implemented and checks whether or not the installer is corrupted on installer initialisation.
You used to be able to turn it on or off (in 1.9) but it's on as default now (I guess).

The GetFileSize function in the Archive works by opening the file and reading it to get the file size. There are various other methods, like using the System plugin to call an API, but the Archive function would be the quickest method.

The only thing that I can suggest, is that you write a program (in any language you prefer) which will make a list of the files which you want to put into your installer (by recursively reading each file name from the directory(s)), or you could do this manually.

You could use a macro for each file like so:

!macro ADD_FILE FILEIN FILEOUT
 File "/oname=${FILEOUT}" "${FILEIN}"
 # do stuff with file here
!macroend

Then for inserting each of the files into the installer, use:

!insertmacro ADD_FILE "path_to\file.ext" "outpath_to\file.ext"

With my NSIS Self-Extractor kit (http://nsis.sourceforge.net/archive/...&instances=0,8) I wrote a script generator consisting of DHTML (JavaScript + [X]HTML), and I used an ActiveX control for a recursive directory includer.
With my Self-Extractor kit, each file could have an 'overwrite if file exists' prompt, therefore I used an !insertmacro (like above) for each file. The script generator read the directory and for each file, it outputted the !insertmacro code for me/whoever to use.

I also once or twice used an NSIS installer itself to generate a list of files from about 10 directories and their subdirectories. If you use an NSIS script, you could also get the file sizes which could be then stored in your main installer for when you want to check for file differences.

-Stu

aportale
19th July 2004 22:05 UTC

Thanks, with all these tricks and solutions I cannot complain anymore .. for now ;).

And the NSIS Self-Extractor kit is very cool. The browser based script generator does a really nice job!

Keep it on!

- Alessandro

Afrow UK
19th July 2004 22:55 UTC

Lol I just ran my script generator just now to create an installer for my HL map, and realised I left an alert in there that says "mo" (uploaded fixed product)

-Stu