BACKVIEW: Directly VIEW backups of the file being edited

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 8:17:46 GMT -5

Quote

Post by Stefan on Oct 31, 2022 8:17:46 GMT -5

Sometimes it can be useful to view a previous version of the file being edited, so one might compare, or even copy/paste data from the backup.

BACKVIEW.MACRO implements an EDIT primary command which will

- display information about available backup generations of the file being edited

- Open a selected backup generation in a VIEW tab in SPFLite

The BACKVIEW command relies on the BACKUP/RESTORE support built into SPFLite.

Therefore it requires that a suitable BACUKP environment has been defined.

Please refer to "Working with BACKUP and RESTORE" in the documentation (most easily reached via HELP BACKUP).

Latest Update 24/08/23, Version 5

V5 Change log:

Prior to version 5, BACKVIEW used an IMACRO override on the VIEW command to tidy up the STATE information.
This meant that the VIEW command did not execute any IMACRO setting specified in the backup file's profile.
Version 5 replaces the im_BV IMACRO with a new macro called BvTidy.MACRO.
This way, the VIEW command will honour any existing IMACRO specified in the backup file's Profile, and still tidy-up the STATE information as before.

If you have used prior versions of BACKVIEW, you can delete the im_BV.MACRO as it no longer being used by version 5.

BackView.MACRO (27.99 KB) The main BACKVIEW command

BVTidy.MACRO (3.68 KB) An assistance macro used by the VIEW session to keep SPFLITE's STATE folder tidy.

You are advised to enter a one-time SET ALIAS.BV = BACKVIEW statement. This will allow BV to be used as an abbreviation for BACKVIEW.

The BACKVIEW command Syntax is:

Display mode: BACKVIEW [ ? [ ALL | n ] ]

? displays the number of available backup generations

ALL displays information for ALL available generations

n displays information for the 'n' most recent generations

The 'information' will be displayed in non-permanent GNOTE> lines in the current edit file.

. the generation number (e.g. -1)

. date-time stamp of file at time of backup,

. date when backup was created,

. file size (in bytes)

. file line count (if available - requires STATE ON in profile)

VIEW mode: BACKVIEW [ -g ]

-g loads generation -g into a VIEW tab, Generation numbers count backwards, -1 being the most recent.

Entering BACKVIEW without any operands will recall the most recent backup generation available (i.e. same as BACKVIEW -1)

Last Edit: Aug 31, 2023 11:21:11 GMT -5 by Stefan

George Administrator Posts: 4,053	BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 9:39:09 GMT -5 Quote Select Post Deselect Post Link to Post Member Give Gift Back to Top Post by George on Oct 31, 2022 9:39:09 GMT -5 Stefan: Very nice addition. Certainly shows what can be achieved in Macros. George

George
Administrator

Posts: 4,053

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 12:33:01 GMT -5

Quote

Post by George on Oct 31, 2022 12:33:01 GMT -5

My 2 cents. I prefer the GNOTES solution, I don't want yet another tab open just to receive some messages. After all, the xNOTE feature was created to help macros insert messages like this.

Also, if the BV overrides the users IMACRO, I doubt it would matter much - a) IMACRO is probably not used very much, and b) supplanting it for purposes of VIEWing the backup, by those few users who ALSO use IMACRO is not worth worrying over.

BackView IS, after all, as assist for those who WANT to use it, it is not some mandatory thing being forced on users.

G.

George
Administrator

Posts: 4,053

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 13:48:37 GMT -5

Quote

Post by George on Oct 31, 2022 13:48:37 GMT -5

But the IMACRO is NOT inserting the comments etc. It is there to 'clean up' the $BACKUP folder of extraneous STATE files.

I'm not even sure it's needed as STATE file eventually 'go away' when they're old enough.

G.

Last Edit: Oct 31, 2022 13:49:51 GMT -5 by George

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 14:27:21 GMT -5

Quote

Post by Stefan on Oct 31, 2022 14:27:21 GMT -5

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.

Last Edit: Oct 31, 2022 15:13:31 GMT -5 by Stefan

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 14:57:21 GMT -5

Quote

Post by Stefan on Oct 31, 2022 14:57:21 GMT -5

Oct 31, 2022 13:57:36 GMT -5 Robert said:

I am unclear here. Who said anything about cleaning up the backup folder? All I had asked for was to SEE the backup folder, not tamper with it.

Plus, if the state file eventually goes away on its own, why have an IMACRO?

Can't have it both ways. (Unless, that's what you meant by "I'm not even sure it's needed". Were you referring to the IMACRO? Again, I am unclear here.)

Gotta say, I don't really want a macro traipsing around altering anything in my $STATE directory. That's why I said it would be a "VIEW" of the backup files, not an EDIT.

Yes, I confirm you are unclear.

a) BACKVIEW does not "clean up" the backup folder. It is called \$BACKUP in the same file path as the file you are editing. BACKVIEW makes no changes here.

SPFLIte's periodic 'pruning' of the files in the various $BACKUP folders will remove expired backup files as well as their related STATE files.

b) The \$BACKUP folder holds both, the backup files and their related STATE files.

BACKVIEW initiates the VIEW command with the filepath\filename of the requested backup file stored in the \$BACKUP folder.

VIEW loads the file (its name unchanged) directly from the \$BACKUP folder, but has NO KNOWLEDGE that the STATE file for that file also resides in the \$BACKUP folder.

Instead VIEW looks for the STATE file in the place where 'live' STATE files are stored, SPFLite's <HomeData>\STATE" folder and fails to find a STATE file that matches the filename of the backup file it loaded.

To avoid this failure, BACKVIEW...

(1) copies the STATE file related to the backup file to be VIEWed, from its location in the \$BACKUP folder to the SPFLite "<HomeData>\STATE" folder

(2) renames the copied STATE file to the particular filename format used for live STATE files, so it matches the filename belonging to the backup file which is to be VIEWed.

(3) when the environment is ready, BACKVIEW issues the VIEW command via POST_DO

(4) then BACKVIEW stops.

c) The IMACRO is needed to "clean up" the SPFLite "<HomeData>\STATE" folder because BACKVIEW had to copy the STATE file into there and it will remain there for ever unless we delete it.

IMACRO is perfect for this because, by the time it executes, VIEW has completed the "load" process, including STATE file processing, so the STATE file is no longer needed.

I hope this makes sense and you're now unconfused.

Last Edit: Oct 31, 2022 15:15:50 GMT -5 by Stefan

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 15:04:23 GMT -5

Quote

Post by Stefan on Oct 31, 2022 15:04:23 GMT -5

Oct 31, 2022 13:48:37 GMT -5 George said:

But the IMACRO is NOT inserting the comments etc. It is there to 'clean up' the $BACKUP folder of extraneous STATE files.

I'm not even sure it's needed as STATE file eventually 'go away' when they're old enough.

G.

George,

The IMACRO doesn't touch the $BACKUP folder. it removes the copied STATE file from the <HomeData\STATE" folder

Are you saying that SPFLIte performs some kind of housekeeping on the "<HomeData\STATE" folder anyway? If so, I wouldn't need the iMACRO, no.

What cleanup happen, and when, plse?

Last Edit: Oct 31, 2022 15:06:05 GMT -5 by Stefan

George
Administrator

Posts: 4,053

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 15:27:17 GMT -5

Quote

Post by George on Oct 31, 2022 15:27:17 GMT -5

Stefan: Cleanup occurs in every $BACKUP folder, but only if an actual BACKUP command creates a backup in it. i.e you can create a $BACKUP folder anywhere you like, but if the BACKUP command never used it, it will not clean it up.

Does that help?

G.

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Oct 31, 2022 16:13:13 GMT -5

Quote

Post by Stefan on Oct 31, 2022 16:13:13 GMT -5

George,

Does this help? Yes and No.

Yes because it clarifies that the $BACKUP folders which SPFLite uses are house-kept.

Given when you backup a data file, you also backup its STATE file, I assume that when you clean-up 'expired' backup files you also remove any associated 'expired' STATE files.

No, because that isn't an issue for BACKVIEW or the IMACRO. (BTW, BACKVIEW only ever 'reads' the \$BACKUP folder data, it doesn't 'write' anything there, nor does it create new $BACKUP folders.)

The question is: Is any 'housekeeping' performed on the "<HomeData>"\STATE folder?

I assume that IF/WHEN a user deletes a data file via FM, you also delete its related STATE file from the <"HomeData">\STATE folder.

But if the user deletes data files (as I sometimes do) via Windows Explorer, SPFLite wouldn't even know.

So it is very likely that, over time, the <"HomeData">\STATE folder will contain 'orphan' STATE files for 'deceased' data files.

BACKVIEW copies the STATE file belonging to a 'recalled' backup file to the <"HomeData">\STATE folder so that VIEW can use it when opening the file.

The IMACRO is designed to avoid polluting the <"HomeData">\STATE folder, by removing the copied STATE file as soon as VIEW is finished with it.

Last Edit: Oct 31, 2022 16:18:12 GMT -5 by Stefan

mueh
Senior Member

Posts: 421

BACKVIEW: Directly VIEW backups of the file being edited Aug 6, 2023 14:17:03 GMT -5

Quote

Post by mueh on Aug 6, 2023 14:17:03 GMT -5

Hi Stefan !
BACKVIEW ? ALL fails under 2 conditions with Version 2 .
1. If filename has no extension it fails with

2. If there is "-" in either path or filename the output is incorrect

to solve it replace lines 171-173 with

    bfn$ = mid$(gDirList$(gen),instr(-1,gDirList$(gen),"\")+1)    ' fn with no path

  for cz = 1 to len(bfn$)-20

  if mid$(bfn$,cz,1) = "." and mid$(bfn$,cz+7,1) = "-" and mid$(bfn$,cz+14,1) = "." and verify(mid$(bfn$,cz,21),".-0123456789") = 0 then exit for                       ' search for backup fn

  next

  if cz >= len(bfn$)-19 then halt(fail,"Backup file name invalid")

    filDt$ = Replace$("DA-MO-20YR ho:mi:se", ANY "YRMODAhomise",mid$(bfn$,cz+1,6)+mid$(bfn$,cz+8,6))                  

    bckDt$ = Replace$("DA-MO-20YR"         , ANY "YRMODA"      ,mid$(bfn$,cz+15,6))

and define cz as number and bfn$ as string .
Thanks for writing this macro .

mueh
Senior Member

Posts: 421

BACKVIEW: Directly VIEW backups of the file being edited Aug 6, 2023 14:36:20 GMT -5

Quote

Post by mueh on Aug 6, 2023 14:36:20 GMT -5

Hi Stefan !
Fix needs additional change to ignore STATE file if no file extension .
line 89
gBckups = Dir_ListArray(gDirList$, _ ' Results -> array

fPath$+"$BACKUP\", _ ' Where - File path

fBase$+fType$+".*"+fType$, _ ' What - File Mask

%File_Normal+%File_AddPath _ ' Retrieve only normal files

uses STATE file as backup generation if ftype$ is empty .
Here a BACKVIEW.macro where STATE files are ignored when no file extension at line 89
In addition one blank GNOTE line at end of backup list .
BACKVIEW.MACRO (14.39 KB)

Last Edit: Aug 7, 2023 3:28:18 GMT -5 by mueh

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Aug 9, 2023 10:05:49 GMT -5

Quote

Post by Stefan on Aug 9, 2023 10:05:49 GMT -5

Thanks MUEH - new version 3 replaces previous in first post in this thread.
I did't realise you'd posted revised version above - sorry. So I recoded bits to remove .STATE files from capture and fix the 'no filetype' issue.
Also fixed the '-' or '.' within the filename error.
Ah well - note to self - Read all posts thoroughly BEFORE changing the program!

Last Edit: Aug 9, 2023 10:11:09 GMT -5 by Stefan

Robert
Graduate Member

Posts: 3,149

BACKVIEW: Directly VIEW backups of the file being edited Aug 9, 2023 10:35:02 GMT -5

Quote

Post by Robert on Aug 9, 2023 10:35:02 GMT -5

I am trying to understand the role of "im-BV.MACRO" in all this. I vaguely recall the discussion of Back View but I haven't seen any of this in a year. Does this mean you have to be using an IMACRO in every profile where you want to use BACKVIEW? Isn't there any other way to do this?

All said, it seems like a pretty clever little macro.

R

Stefan
Administrator

Posts: 989

BACKVIEW: Directly VIEW backups of the file being edited Aug 21, 2023 11:00:07 GMT -5

Quote

Post by Stefan on Aug 21, 2023 11:00:07 GMT -5

Hi Robert,

There's no need to change any profiles.

When a backup version is selected, the BACKVIEW macro executes a SPF_Post_Do("VIEW '"+<backup-filename-here>+"' %im_BV") to pop up a new tab containing the requested file.

Note the %im_BV override on the VIEW statement to call the im_BV macro after VIEW loads the file - no profile change needed.

Why is the macro needed? Basically, to tidy up after some files.

If the backup-file has an associated STATE file, some extra jiggery-pokery is needed to ensure SPFLite honours the STATE file when VIEW loads the file.

The relevant STATE file is in the same $BACKUP\ folder as the backup-file. But when loading any file, SPFLite expects the associated STATE file to be in the <homedata>\STATE\ folder.

Hence BACKVIEW copies the associated STATE file from the $BACKUP\ folder to SPFLite's <homedata>\STATE\ folder.

VIEW comes along, loads the file and the relevant STATE file is applied as usual.

At the end of the loading phase, the im_BV Imacro is executed and deletes the copied STATE file from the <homedata>\STATE\ folder to tidy up, as it's no longer needed.

Given that the im_BV override replaces any IMACRO which may be specified in the backup-file's Profile, I may change BACKVIEW macro to only add the override IF the backupfile to be viewed has a STATE folder.

Hope that explains it.

BACKVIEW: Directly VIEW backups of the file being edited

Post by Stefan on Oct 31, 2022 8:17:46 GMT -5

Post by George on Oct 31, 2022 9:39:09 GMT -5

Post by George on Oct 31, 2022 12:33:01 GMT -5

Post by George on Oct 31, 2022 13:48:37 GMT -5

Post by Stefan on Oct 31, 2022 14:27:21 GMT -5

Post by Stefan on Oct 31, 2022 14:57:21 GMT -5

Post by Stefan on Oct 31, 2022 15:04:23 GMT -5

Post by George on Oct 31, 2022 15:27:17 GMT -5

Post by Stefan on Oct 31, 2022 16:13:13 GMT -5

Post by mueh on Aug 6, 2023 14:17:03 GMT -5

Post by mueh on Aug 6, 2023 14:36:20 GMT -5

Post by Stefan on Aug 9, 2023 10:05:49 GMT -5

Post by Robert on Aug 9, 2023 10:35:02 GMT -5

Post by Stefan on Aug 21, 2023 11:00:07 GMT -5