Robert,
You raise a number of points.
Bug in your BACKVIEW.
I reckon that's out of my hands. IF it IS a bug, it is in SPFLite itself.
BACKVIEW obtains the current file path and file name using the GET_FileName$ and Get_FilePath$ functions.
It then searches the File-Path for a $BACKUP folder.
If found, it locates the relevant backup files using the File-Name.
When the Get_FilePath$ function provides incorrect information, BACKVIEW has no way of knowing or correcting it.
You switching between two EDIT tabs reveals an SPFLite issue.
Note the distinction between the results returned by Get_FileName$ and Get_FilePath$ as described in the Help Documentation.
Get_FileName$ states: "Returns the filename of the current edit file. e.g. MYFILE.TXT" <= Note the word 'edit'
Get_FilePath$ states: "Returns the current file path for the current file. e.g. C:\Users\Me\Documents" <= Note the word 'current' instead of 'edit'
The effect you observe is because after a tab switch, GET_FilePath$ returns the 'current' file path which usually, but not always, the edit file path.
SPFLite should be consistent and return the filepath that belongs to the current edit tab environment, not the one most recently stored in File Manager.
The effect is also mentioned in the Help document for the Get_FullPath$ function, which states:
" Returns a fully qualified filename including Drive:\path\filename
If the macro call is issued from a temporary session (CLIP, Set-Edit, (Empty), etc.) the path returned will be the last displayed path in File Manager.
If the call is issued from a normal Edit/Browse session, the path assumed will be that of the currently loaded file. " <== Note the word 'assumed'
NUMBER vs LONG I admit I'm a little confused and will bow to greater knowledge if I'm mistaken. When I issue a HELP THINBASIC command and search for LONG, then select "Numeric Variables", the documumentation states:
" Restrictions
1. thinBasic perform all internal numeric calculations using EXTENDED (abbreviated EXT) data type.
2. due to lack of precision (only 6 digits), we suggest to use SINGLE data type only when interfacing to external libraries that explicitly ask for SINGLE parameters passed by reference.
3. Numeric data type is an alias of EXT (Extended) "
Given point (1) assertion about "...all internal calculations..." , I guess that we should probably always use EXTENDED to avoid numerical conversions at execution time. Given that integer arithmetic is usually faster, this seems just wrong.
Interestingly, the word NUMBER isn't mentioned here at all but I assumed as 'numeric' is not a data type, that the word 'numeric' in point (3) is a typo for 'NUMBER' .
NUMBER IS mentioned in the HELP description of the DIM statement:
" VariableType can be any of the primary variable types supported by thinBasic:
BYTE, INTEGER, WORD, DWORD, LONG, QUAD, SINGLE, DOUBLE, EXT, CURRENCY, STRING, ASCIIZ, VARIANT, GUID, NUMBER "
So I'm really not sure what to believe for best performance. (I've become quite accustomed to the fact that thinBasic does not equal Powerbasic is several respects).
IMACRO
I take your point about adding an IMACRO-override to the VIEW statement, but your proposed CLIP approach doesn't help here.
In order for the VIEW command to load the requested backup file properly, i.e. including its STATE information, two things need to happen:
(1) the backup version of the STATE file that accompanies the requested backup file must be placed where the VIEW command expects to find it.
There is only one place where STATE files are referenced and that is the SPFLite "<HomeDatar>\STATE", not the $BACKUP folder where the backup file is located.
(2) The requested backup file's STATE file must have the ruight filename and not the filename which it had in the $BACKUP folder where it was stored.
BACKVIEW takes care or copying the STATE file to the "<HomeData>\STATE" folder and renames it to the required filename, so that VIEW can use it to load the file.
But AFTER VEIW has loaded the requested backup file, the, now useless, STATE file remains in the <HomeData\STATE" folder. Over time, these file will pollute the common STATE folder.
BACKVIEW cannot clean up the <Homefolder\STATE" folder as it has already finished, but the IMACRO execting after the VIEW file load can.
I took the view that using the STATE file and subsequent cleanup was better than the more unlike event that the file-type being VIEWed needs an IMACRO.
In any case, the text under HELP VIEW states:
" [ %imacro-name | %ON | %OFF | %NONE ] " <--- What's with the % prefixes for ON and OFF? Should they be '/' or blank ?
and
" %imacro-name
This optional operand allows you to specify an IMACRO (a macro to be run immediately after the file is loaded). If an IMACRO is specified in the file's Profile, this imacro-name will override it.
You can use /OFF or /NONE to nullify an IMACRO specified in the Profile
You can use /ON to activate an IMACRO in the profile which is save in OFF mode."
I didn't code /OFF on the VIEW statement as that appeared to be implied by the "...will override it" statement.
