Log File Verbose not so Verbose

[Jason Pate]

Log the maximum amount of information for all actions. This includes the script line numbers and events, the action and its return codes.


Verbose does not seem to be very verbose, has anyone else noticed this? Above is the description of Verbose from the help file. I have attached my sf7 project, and the resulting log file. I dont see any actions included?? The resulting file does not seem to match the helps description of Verbose.

Now this installer is running fine currently, so this is not a huge deal, but when something goes bad on a end users machine the log files is usually all that I have to go on to figure out what happended. So I like to see a log file like the old sf6 Actions name, settings it used, and the result code. Line number would be handy as well. And what's its screen/tab or something showing the what Actions window it came from.

Please let me know if I am miss reading this log file, or if something is really missing.

[JXBURNS]

Don't forget you have the ability to switch on debug mode which is designed for this purpose at runtime.

John

[Jason Pate]

Yes and that is what I am using to get by, but I love me a good log file. That way when one of my co-employees says BUT jason your installer did this, I can goto the log and say no I did not do that

[Ted Sullivan]

We're taking a look at that. In the meantime, you can write out anything that you want using the SetupData.WriteToLogFile action. It "Writes a string of text to the install or uninstall log file". Here are some examples.

SetupData.WriteToLogFile ( 
 string  Text,

boolean AddTimestamp = true )
 

Example 1
SetupData.WriteToLogFile("ERROR: " .. Application.GetLastError(), true);

Outputs the current application error to the install or uninstall log file.

Example 2
err = Application.GetLastError();

if err ~= 0 then
    sMessage = "####################\r\n" .. "ERROR " .. err .. ": " .. _tblErrorMessages[err] .. "\r\n####################\r\n";
    SetupData.WriteToLogFile(sMessage, false);
end

If an error occurs, outputs a nicely-formatted string into the install or uninstall log file.

[Jason Pate]

Thanks for the info Ted, I guessing this is a bug that will get patched, I will keep the SetupData.WriteToLogFile in mind.

[Jason Pate]

I am hoping that more details on actions in the log file will be in the next build this is cousing me delays in development.


[10/12/2004 16:55:44] Error Script: On Post Install, Line 89 (1000)

Error like that is usefull, but it sure would be nice to know what FILE its lookings for sence I specifically hard coded a path to a file, I am sure I will figure it out soo, but it would be so much nicer if the full action details were in the log file. That way I would know right off the bat.

It does not match the help files description for Verbose. (see below)

Log the maximum amount of information for all actions. This includes the script line numbers and events, the action and its return codes.

[Jason Pate]

sorry I posted this to the wrong subject

[Brett]

This has been fixed in version 7.0.1.0

It now has working error modes in the runtime.

[Jason Pate]

Just got your email downloading and installing update now. Thanks

[Jason Pate]

Ok I downloaded 7.0.1.0 the log is better but still not quite right. The variables are not expanded in the log. It simply gives me my line of code.

File.Copy(test, appfolder, true, true, false, true, nil)--funfilecopydisplay

What I want to see in the log is File.Copy(C:\jason\*.*, C:\billy\, true, true, false, true, nil)

Something likes that. If the variables are not expanded I would have no idea if ther is some path issue/mistake. If test/appfolder have bad paths in them I need to see that in the log file. I know I can see it in debug mode, and trust me I LOVE debug mode for development. But I depend on log files for debug if it fails in the feild or in Quality control. (The Quality Control is done by another group in my company when the setup fails during QC, all I get back is the LOG file so all I have to go on is the log files to see what happened, don’t always have time to sit and run it in debug mode on QC machine(s)) This is not just about a File,copy actions, this is all actions.

Don’t get me wrong I love the fact that I now get a error line number that saves me tons of time. And the error number is nice too. But I want to know what the action was doing, and how it was trying to do it. The problem could be what’s in the variable and most lickly is than the line of code itself LUA is so dang picky a missing \ or .. can really blow away your script or make actions totally fail. I am happy to delivery an example(s)

Yes I realize this can eat up a LOT of hard drive space but I could careless about that, and yes I also realize it will slow down the installer but I need to know what happened more than either of these concerns. I need to SHOW what the installer did. I have to be able to defend myself if the he said she said blame game starts.

[Performing Actions]
START: Perform action: Copy Files
Source = D:\setup\path.ini
Destination = C:\DOCUME~1\Michael\LOCALS~1\Temp
Recurse subdirectories = FALSE
Overwrite existing files = TRUE
Continue copying files even if one or more fail = FALSE
Copy hidden and system files = FALSE
(On Error) User notification mode = Custom
Custom Message = Could not copy file %LastErrorDetails%



Setup was unable to copy 1.exe to %TempDir%,

After MSAccess install and reboot Please manually

run 1.exe
(On Error) Action = Continue
Result = 0
END: Perform action: Copy Files

Sorry I did not mean to ramble on for so long; this is just a concern of mine. I really hope to see it get adjusted. I do like SF7 and see that in many ways its better than sf6, and I have come to far in the learning curve to stop now. Please just expand the variables in the log file. WHO knew that anyone cared about a silly log file this much LOL thanks for reading this over.

Hi Jason...

Just my 2 Cents on a couple of things and how I personally try to view 'developing'...

LUA scripting errors: I treat these as 'my problem-my responsibility'
--these should show up during development- and pre-release TESTING etc.

How much 'error' handling I include in my 'scripting' etc.
can help identify things...during creation-testing.
(strategic Dialog.Message boxes to return 'test values helps me a lot)
--totally separate from Debug Mode as it were.

A thought...could create or append some 'actions checks' - based on
script 'error handling returns' to the Log as you go. Or code to create a separate Log and 'append' this to the 'main log.

Anyway..these are just a couple of my Personal viewpoints only.

[Brett]

Jason,

If you want to output errors with more information I would suggest that the best way to do it woul dbe to write a custom error handling routine. Do Something like this:

function HandleError()
local nLastError = Application.GetLastError();
if(nLastError ~= 0)then
-- Do whatever you want here
-- Log out to LOG file, show error dialogs, or whatever
end
end

Then in your code, call this function after each function call:

File.Copy("C:\\Myfile.txt",strDestPath);
HandleError();

You can go as far as you want in logging out variable values and error messages. Our challenge was to make the product robust and appeal to what we percieve most users want to accomplish. However, we have built the flexibility in to let you do anything you want to.

[Jason Pate]

SUF6NEWBIE,

As always thanks for your 2 cents communication is appericated. I agree LUA coding errors are my mistake, in my installers. And of course I want to handdle all the errors that I can inside the script. But there are things that as developers we cant predect, like how files are layed out on the end users system. Or the options that a user selects during the install.

I want to know not just the failed actions, I want to know the successfull ones, just because something was successfull, does not mean it was not in part why it failed.

I am requestion is a log of what the installer did, failed or succeeded. It does not happend often, but more than once my installer has failed or done unexpected things in the feild, I read through the log file, see what it did and adjust the next ver of the installer.

My installer does a LOT more than just copy a few files onto the end users install, my sf6 has 100's of lines of code (500), to try to manual create a error handdling for each line is crazy, in SF6 a simply warn users or not and continue or not was handdled Automadically by SF, I could even make a custom error message. Yes I know I can still do that, not as easy have to make script for it, and I will.

I just want a record of what SF does on the end users system. The reasons I am requesting this is because it has saved my A** in the past, also it has made it so I can improve the behavor of the installer in my next release.

[Jason Pate]

function HandleError()
local nLastError = Application.GetLastError();
if(nLastError ~= 0)then
-- Do whatever you want here
-- Log out to LOG file, show error dialogs, or whatever
end
end

Is great and helpfull, I guess I will have to use it. I just have this feeling things have more complext and I have lost features that I had in sf6. I am just learning functions and I think adding HandleError() after each line is not the end of the world, just so much I am already learning to get this sf7 stuff down. I will give it a try, but please consider a complete actions log. If I am lucky a few others users will need this, and request it.

Jason

"I just want a record of what SF does on the end users system. The reasons I am requesting this is because it has saved my A** in the past, also it has made it so I can improve the behavor of the installer in my next release."

I'm with you all the way...getting used to LUA and the extended functionality
it offers is well worth the perseverance.

It is not uncommon for LUA Code to reach 5000 lines of 'tweaked' code
...depends on what we want to buildin and the functionality etc.

Using Functions (error output handler as BRETT offerred) etc will become
'bread and butter' with SUF7...if you like many others wanted and wish to
do, extended functionality beyond basic 'install Files'
SUF6 is a great program.....SUF7 ..with LUA..goes a lot further in the 'Possibilities' .

Keep at it ....