Help - Search - Members - Calendar
Full Version: NLite Session Ini
MSFN Forums > Member Contributed Projects > nLite

   
Google Internet Forums Unattended CD/DVD Guide
Quisquose
I tried to slipstream some hotfixes into an install and during the process got warned by NLite that one of the hotfixes was not of the expected type (it was therefore skipped).

However, when I checked my NLite session ini, the file was still listed in among all the other hotfixes with nothing to distinguish it and comment about the fact that it had not been added.

Might it not be a good idea to have this line REMd out with a comment, so that when you go back to look at the session ini later, it more accurately reflects what has been actually been done rather than what was attempted?

Just an idea.


Thanks
Speeddymon
QUOTE (Quisquose @ Dec 22 2006, 04:44 AM) *
I tried to slipstream some hotfixes into an install and during the process got warned by NLite that one of the hotfixes was not of the expected type (it was therefore skipped).

However, when I checked my NLite session ini, the file was still listed in among all the other hotfixes with nothing to distinguish it and comment about the fact that it had not been added.

Might it not be a good idea to have this line REMd out with a comment, so that when you go back to look at the session ini later, it more accurately reflects what has been actually been done rather than what was attempted?

Just an idea.


Thanks

Unfortunately the way last session.ini works, it shows what was specified by the user. The notes would be a good idea, but it is created before the process actually goes thru and makes the changes as far as I can tell, so there is no way for nlite to know if errors were encountered.
RaGhul
hmmm....
That would be a good feature to include with nuhi's v1.3 Final, I think.
(Hint, hint.) yes.gif
Speeddymon
QUOTE (RaGhul @ Dec 23 2006, 04:45 AM) *
hmmm....
That would be a good feature to include with nuhi's v1.3 Final, I think.
(Hint, hint.) yes.gif

My point is that the way nlite is currently written (if it does things the way I stated above), it would take a complete rewrite for that to happen. I dont think that will happen between the 2nd beta, and final
Ver Greeneyes
A complete rewrite seems a bit much tongue.gif nLite could simply look in the log and if any errors are found write them to some file; the last session.ini could work since nLite has the syntax for that anyway.
Quisquose
QUOTE (Speeddymon @ Dec 23 2006, 07:37 AM) *
... it is created before the process actually goes thru and makes the changes as far as I can tell

Ah, ok.

I'm not a programmer (so I don't really understand these things). I thought that it would be quite trivial to implement.


QUOTE (Speeddymon @ Dec 23 2006, 07:37 AM) *
... so there is no way for nlite to know if errors were encountered.

Sorry, I don't understand that bit. NLite does know if errors have been encountered. It's NLite that tells me (it pops up a dialog saying so).

If the session ini file has already been created at the beginning of the process (at time that the hotfixes are added) then the file already exists and so it can have text added to it by the 'process' that generates the error pop up dialog. (Excuse my inaccurate programming terminology).

There must be code somewhere that performs the function "if file is not of correct type, then pop up dialog to warn user". So all that needs to be added is "and then add a comment to the existing session ini file".

NLite would not need to know of these errors before hand, it would just write them into the pre-existing session ini as each inividual error was encountered (during the NLiting process).

But maybe I am over simplifying matters.
Speeddymon
QUOTE (Quisquose @ Dec 23 2006, 08:34 PM) *
QUOTE (Speeddymon @ Dec 23 2006, 07:37 AM) *
... it is created before the process actually goes thru and makes the changes as far as I can tell

Ah, ok.

I'm not a programmer (so I don't really understand these things). I thought that it would be quite trivial to implement.


QUOTE (Speeddymon @ Dec 23 2006, 07:37 AM) *
... so there is no way for nlite to know if errors were encountered.

Sorry, I don't understand that bit. NLite does know if errors have been encountered. It's NLite that tells me (it pops up a dialog saying so).

If the session ini file has already been created at the beginning of the process (at time that the hotfixes are added) then the file already exists and so it can have text added to it by the 'process' that generates the error pop up dialog. (Excuse my inaccurate programming terminology).

There must be code somewhere that performs the function "if file is not of correct type, then pop up dialog to warn user". So all that needs to be added is "and then add a comment to the existing session ini file".

NLite would not need to know of these errors before hand, it would just write them into the pre-existing session ini as each inividual error was encountered (during the NLiting process).

But maybe I am over simplifying matters.

It is a good point, perhaps just an added section to the end of the file that is called the errors section? I actually didnt think of that, which is why I'm not the one that writes nlite lol
Quisquose
QUOTE (Speeddymon @ Dec 24 2006, 02:47 AM) *
perhaps just an added section to the end of the file that is called the errors section?

Yes, that would work, but I was initially thinking more along the lines of "rem-ing" out the problem hotfix (e.g. with a semi colon) rather than simply documenting its failed integration.

Otherwise if you re-load your lastsession.ini (which a lot of people will do) you will keep encountering the same errors over and over again, because NLite will keep trying to install the incompatible fixes that are listed in the [Hotfixes] section of the session ini (regardless of any notes at the end of the file).

Automatic 'rem-ing' out these problem entries would ensure that (on subsequent use of the session ini file) these incompatible files would be skipped automatically, theyby not cause the NLiting process to stall on an error dialog waiting for user input to skip the file.

Without this, the user is left to remove the entry manually, and unless they have a very good memory (or the foresight to write down each individual Hotfix string from the NLite error popup) then they're not going to know which files to remove because there is absolutely no indication of them after the NLite process has completed.

However, you raise a good point about a section dedicated to errors.

By moving the hotfix entry from the [Hotfixes] section (rather than rem-ing it out), it would make it much easier to find which files have failed to install. It would certainly be easier than searching for certain items preceded by a semi colon buried in a long list of entries.

Also, the fact that the problem entries are no longer under the [Hotfixes] section would mean that NLite would not keep trying to integrate those files when that session file is re-used.

Additionally, comments on the nature of the failure could be kept along side the hotfix entry to which it relates, without messing up the neat list of items in the [Hotfixes] section. This could not be done if the problem entry was REMd out 'in situ' (because any comments would be in another section away from the hotfix entries).

I'm sure Nuhi could do basic text manipulation like that in his sleep (and with one hand tied behind his back).

tongue.gif
Google Internet Forums Unattended CD/DVD Guide
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.