|
|
Post by George on Nov 6, 2022 14:42:47 GMT -5
Robert: Nothing is ever simple. MEdit is a good example.
You've forgotten you can issue a "MEDIT filename" command from any old Edit session and convert the session to a MEdit one and ADD the specified filename.
In fact, what FM does when you select a bunch of files with "M" commands is to build a whopping big command line that says
"MEDIT NEW filename-1 filename-2 filename-3 etc. (The internal "NEW" keyword just indicates a new tab is to be created.)
So even if FM somehow maintained this list, what happens if a user, in an existing MEdit session, does a "MEdit filename-x" command. Now we have a filename in the 'list' which wasn't in the original FM list. And also, what happens when there are multiple MEdit tabs open? Or if the MEdit session wasn't even started from FM?
So FM can't play a part in this. I suppose a BACKUP could trigger a Backup for each item in the MEdit session, but RESTORE would remain an individual file restore. i.e. you could not "Restore" a complete MEdit session.
George
|
|
|
|
Post by Stefan on Nov 7, 2022 5:46:19 GMT -5
<snip> In fact, what FM does when you select a bunch of files with "M" commands is to build a whopping big command line that says "MEDIT NEW filename-1 filename-2 filename-3 etc. (The internal "NEW" keyword just indicates a new tab is to be created.) <snip>
Hmm...
If Robert needs control over the order in which the files appear in the MEDIT session, could that be achieved by manipulationg the order of the names in your 'whopping big command line"? I may be way off base here, having only used MEDIT once, but I can see the attraction in having files appear in a particular sequence.
If the sequence in the 'whopping list' is relevant, could you allow the 'M' line commands that are used to select the participants to have a 2nd character? What if Robert could enter "MA", "MB", "MC", etc (possibly avoiding MM) where "MA" is loaded before "MB", etc and all such lines are loaded before those selected with plain "M" or an "MM...MM" block? Not as smooth as having some kind of SORT ability but it would allow an element of sequencing without tampering with time stamps, etc.
Or could the MEDIT primary command take a pre-built FLIST as source for the 'whopping command line' and load the files in the order specified therein?
|
|
|
|
Post by George on Nov 7, 2022 12:05:14 GMT -5
Robert: Build an FLIST with files in the 'correct' order. I have such a list for SPFLite. Then choose the NAME* sort for it. Here's what my FLIST for _SPF2.FLIST looks like, so that the _SPFLite.BAS file comes first. D:\Documents\SPFLite2\_SPFLite.bas|*
D:\Documents\SPFLite2\*|+_*;-CFG*;-*.log;-*.EXE;-_SPFTest.bas;-_CFGMaint.bas
Or you could just add a bunch of specific full file names. All I do then is issue an ALL M to enter MEdit on the whole source. And I can use my PB macro to do the compile [and run] right from the SPFLite session. I only need the PB IDE if I want to use the debugging abilities. The extra filters above are just to eliminate the 'noise' files located in the same folder. George Here's my PB macro. A small BAT file needed is in the macro comments. PB.macro (4.74 KB) George |
|
|
|
Post by George on Nov 7, 2022 12:19:00 GMT -5
Robert: On the original topic - BACKUP/RESTORE in MEdit - Re: making the contents of the FM Screen an Object.  - EVERY tab in SPFLite is an Object, that's how data isolation is handled. So FM is an Object, every MEdit session is an Object, every normal Edit, Browse, View and every SETEdit, CLIP, etc is an Object. And that fact is why cross-tab communication is such a bugger, Tabs are not SUPPOSED to talk to each other. And why all tab start-up and shut-down is handled very carefully to circumvent the normal 'can't see "A" from "B" problem. So suggesting we start having tabs pass stuff back and forth to and from FM is a big non-starter. I'll look at BACKUP and RESTORE, but from the point of being ISSUED in the MEdit tab. No FM involvement. George |
|
|
|
Post by George on Nov 7, 2022 15:05:11 GMT -5
You know it's actually trivial to access multiple tabs data areas at the same time, it's just very dangerous since you actually have to 'vet' every SUB/FUNCTION/METHOD you call to make REALLY sure it does just what you want with just the data you want and doesn't stray afield and call some other routine itself which isn't so careful. A good example is DIFF, which accesses data in two tabs.
Frankly for what it would buy, adding some kind of Cross Memory Services just isn't worth opening that door.
There's lots of stuff which could be done, it's just that most of them are extremely disruptive. At this stage neither SPFLite nor I need the headaches.
George
|
|
- EVERY tab in SPFLite is an Object, that's how data isolation is handled.