CFG File Maintenance

Hi Stefan,

I also note that the selection dialog's 'Files of type' field shows EXPORT...

You: The file mask for the OpenFile dialog is "*EXP*.TXT" so it will not show ALL files.

Perfect.

You: Sorry, I disagree, they are all TXT files, no need to pretend they're not.

No worries.



The default mask only shows the EXP files (e.g. not the LOG files, even though they are all TXT files), If you pull down the EXPORT, there IS an All Files option which will show everything.   Or am I missing something here? It looks fine to me.

BUGS - command line operands

(1) There is an error in the handling of the command line operands. I'm pretty sure it relates to trailing blanks.

I have experienced cases where the command syntax looks fine, but the pop-up message reads "Cancelled, Command line operand: is not recognized"

You: Got an example?

Yes - Type CFGMAINT -EXPORT and type a blank after the word EXPORT. It applies to any CFGMAINT invocation with operands, even CFGMAINT -EXPMAX 3<blank> will trigger it.

OK, Found.  It turns out the PowerBasic IDE, where Cmd operands can be specified, seems to do it's own TRIM, which hid the error from me. It's properly corrected now.


(4) It appears that the -EXPMAX operand is allowed with -IMPORT and -REPAIR also. Was that intended?

For Import and Repair, yes EXPMAX is just noise. It's another case of parsing, order of operands, and just how far to go in coding to handle all user stupidities.

Agree in principle. But the user may have added it to deliberately change the EXPMAX value, and presumably that would only take effect if -EXPMAX is used with -EXPORT.



I'll restrict EXPMAX to EXPORT only.


BUG

CFGMaint -IMPORT

(1) opens a pop-up window when complete, stating that "... n entries were corrected", but there is no LOG file to tell the user WHAT was corrected/changed.

Are you sure it didn't say 0 entries were corrected. Or are you saying if zero it should not display the count. Everywhere the count is incremented the code also sets the flag to force the Log to be created.


(2) There are inconsistencies between the export and import processes. Repeatable example:

(a) Export a file - no errors listed.

(b) Import the same file and the first message reads "Import file validation complete" and is followed by "CFG entries re-loaded successfully, 1 items were corrected".

(c) Repeat steps a & b and the same result persists. So what's being corrupted/changed and when?

You: What did the log say was corrected?

LOL... see previous BUG entry, there is no log file. Note it also applies to REPAIR below.

According to the code, not possible.  So ... please send me the CFG file.


CFGMAINT - REPAIR found that

Table: ODEFAULT, Entry LASTSCRY Contains an invalid value: -8 Replace with Default value: 5

As with IMPORT, there was no LOG file written to confirm this message / action taken.

You: Looks like the valid range for LASTSCRY needs to be adjusted.

Hmm.... see next comment below



On a subsequent repair attempt I received

Table: ODEFAULT, Entry SCRPOSITION Contains an invalid value: 1712,3207,-13,826 Replace with Default value: ?

I deliberately provoked the 2nd message by sliding the SPFLite window down so that the bottom edge of the window was off the 2nd display before closing SPFLite.

It might therefore be advisable NOT to flag such negative values as errors.

You: Not having the luxury of multiple displays, I can't even test this. I'll see if message suppression of some kind can be done.

I believe Message suppression is the wrong way to go.

Maybe some values (especially those reflecting external characteristics) should not be reset to arbitary defaults.

Anticipating every possible valid 'environmental' range may be impossible.

REPAIR is right to warn users of odd or inconsistent values but maybe replacements should be restricted to values for which

(a) a valid default exists (i don't consider "?" a default for screen position) and

(b) that have potentially unwelcome knock-on effects on data handling or dire consequences for SPFLite internal operations.

I deliberately closed SPFLite down with its screen positioned partially outside the display, before running REPAIR. I did not allow the repair to fix this setting. When I restarted SPFLite, the screen re-appeared exactly where I had left it. Restarting SPFLITE with the second display disabled, opened the SPFLite window in the 'slightly off page' location on the primary screen. In both cases, a simple switch to MAXimised window corrects the placement, as would a drag up to reverse the situation. So this isn't something REPAIR should need to fix at all.


I'll have a look at creating a "warn only" type validation


In Addition to yesterdays BUG list, I note that...



Something (I think it is SPFLite itself) keeps adding DEFTYPES and DEFTYES to the ODEFAULT table.

These entries are OK as far as EXPORT and IMPORT are concerned, but REPAIR flags them for removal every time. I guess they shouldn't be there (one looks like a typo anyway)


I'll do a scan of the main source, looks like some crap exists somewhere.

This in turn leads me to think that REPAIR uses a more comprehensive validation method than IMPORT or EXPORT.

This is welcome as it allows anyone who tinkers and reloads a CFG to perform a reasonable cross-check of the various entities by running a REPAIR after Import.



However, it also shines a spotlight on another aspect of CFGMaint.



You are now burdened with maintaining several bits of 'validation code' for -IMPORT, -EXPORT and -REPAIR every time you make a change to SPFLite that adds/removes/replaces a setting or setting value in one of the CFG tables.

This is possibly exacerbated by the premise (if I understand correctly) that -IMPORT relies on the next invocation of SPFLite to complete any entries in CFG tables for which the import deck did not provide values. As it stands, there doesn't appear to be a single instance of 'truth' for the CFG.



To avoid this, what if you designate CFGMAINT -REPAIR the 'owner' of the CFG file?



So CFGMAINT -IMPORT would do its thing as today, and then call -REPAIR under the covers to effectively verify, and, where necessary, complete missing entries in the CFG.

No need to wait for the next invocation of SPFLite to plug the gaps.



If SPFLite should notice a (any) gap(s) on invocation, it could close the CFG, call -REPAIR code to fix things and reopen the CFG before continuing with startup.

No need to have code and default definitions in both SPFLite and CFGMAINT.



All the code and valid ranges and default data required to build a 'good' CFG file then rests in one place, CFGMaint -REPAIR, and only that place needs to be maintained when changes to SPFLite introduce new structures in the CFG.



Of course, If you'd prefer to have SPFLite as the CFG 'owner', externalising the fix-up code & associated values in a module that CFGMAINT can call to run -REPAIR would also work.

All the functions use the same common validation routines.  And missing items are filled in by CFGMaint now, not left to the SPFLite code.

George,

Stefan: OK, I'll try your step by step scenario, should be sufficient to duplicate the problem.

Thanks,
George

[UPDATE]

There are none so blind .....

That's me, a real Duh! error.

OK, I think now we have a good one.  I can run through your scenario and everything seems to do exactly what we want.  I've also tidied up some more of the messages and table entries.

Try this one out, should be much, much better.

CFGMaint.EXE (203.5 KB)

[\UPDATE]

Stefan: No idea n the funny named download, I download it normally, and the upload to the forum is also done in exactly the same way.

Very odd. Anyone else experiencing this?

Stefan: Software updates can be a pain.

I download a lot of TV viewing (mainly because the downloaded stuff has already had the commercials stripped out). It takes a variety of software packages to make it all work smoothly (Sonarr, QBittorrent, PLEX, Jackett) but once setup, it works great. Until it doesn't. Then it takes a lot of digging to find out that ONE of the pieces has updated and introduced a bug - in my case QBittorrent.

Thank God for online forums etc. where you find you're not alone and what the fix/bypass is.

Yes, it's 'free' software, but I really doubt it would be any better if it was paid software.

George