|
Post by George on Jul 11, 2023 8:15:26 GMT -5
Robert: I have a macro that tries to do the MEntry validation, but it doesn't work too well. Normally this isn't a big problem since changes are usually localized and only a few routines have to be manually scanned to find the culprit. In this EFT case, that unfortunately isn't the case, there are significant changes throughout the code.
Re: the extension you requested. Everything is 'possible'. I can see the EFT override, but when you want to customize it with possible command overrides and/or where the open originated it rapidly gets into kludge mode.
George
|
|
|
Post by Robert on Jul 11, 2023 10:27:40 GMT -5
I am going to rewrite this (after my [late] breakfast) and maybe it will make more sense then.
R
|
|
|
Post by George on Jul 11, 2023 13:42:51 GMT -5
Robert: Struggling with some old support. Do we really need the SaveAsMEdit stuff? I honestly can't believe it has ever been used. I had to go read help even to learn what it was SUPPOSED to do.
Actually, there's a lot of old stuff I'm coming across in there that is of equally dubious merit. (Like all the RENUMBER NUMTYPE etc. stuff, which I'm also sure is totally unused)
We're carrying around a lot of excess baggage.
George
|
|
|
Post by Robert on Jul 11, 2023 15:22:42 GMT -5
The numbering support was intended for mainframe users, used to the old 73-80 sequencing stuff. I do believe there are a certain number of mainframe users still out there, though the number is pretty small. I personally don't use my Hercules any more; I am not even sure if I could remember how to start it.
I'd say, if it's really a problem, ask around. Maybe no one cares. But if it isn't an actual impediment, I wouldn't remove stuff if it still works.
As for SaveAsMEdit, I don't know what you are referring to. Perhaps you can refresh what little working memory I still have left.
R
|
|
|
Post by George on Jul 12, 2023 8:15:59 GMT -5
Robert: SaveAsMEdit is a fork off SaveAs if it's issued in a MEdit session. i.e. How to give new names to a pile of files?
So it asks for, and creates a new folder and saves the whole set of files into that folder. I just have a hard time picturing using SPFLite to perform what is basically a folder copy the hard way.
Like the Number stuff, we've created lots of stuff which is "well, yes, I can picture a use for this" so it gets created and then ignored by 99.9% of the users. We have a lot of hammers looking for nails. I'm tired of fussing and fiddling with stuff like this.
George
|
|
|
Post by Robert on Jul 12, 2023 11:23:01 GMT -5
OK, now I remember. (And yes, DO blame me.) The point of all this is, "hey, I really want to do an MVIEW or MBROWSE, but I can't". So, SaveAsMEdit makes a copy of the current MEdit session, so that you can look at the whole shmear of files without risking a modification to any of them.
Honestly, if you could manage it, having an MVIEW could be more useful and maybe less complicated.
Real question is, is there any demand for a non-updating MEDIT?
Here is maybe a different (better?) question: Is there any demand for a READONLY command? The command wouldn't actually set the R/O file attribute. It would just set a flag in SPFLite that says, "I don't care how the file was opened - just NEVER update it."
The actual name of this thing isn't critical; I can think of a half a dozen different ones,
UPDATE ON/OFF WRITE ENABLE/DISABLE
but I think I like MODE the best:
MODE EDIT/VIEW/BROWSE
Just a thought.
P.S. If you could inject a command during EFT override time, the concept of PROFILE SELECT BROWSE could be accomplished by inserting a MODE BROWSE at open time.
R
|
|
|
Post by George on Jul 12, 2023 14:57:57 GMT -5
Robert: Well MODE has appeal, especially with my latest changes, there isn't any difference between different sessions except the state of one flag. However, switching a tab fom EDIT to VIEW with MODE also means you can switch from VIEW to EDIT just as easily. That could be a problem perhaps? Maybe MODE should only allow changing to a MORE restrictive MODE. i.e. EDIT -> VIEW -> BROWSE
Then I guess if MODE becomes an available EFT override, how do we get out of the following: * EFT for a file contains MODE BROWSE * How does one EDIT the file? EDIT filename will override to BROWSE. And MODE won't allow BROWSE -> EDIT Maybe MODE needs another operand - FORCE
Also if you want MBROWSE - what happens to the FM "M" line command, which assumes MEDIT?
George
|
|
|
Post by Robert on Jul 12, 2023 17:59:53 GMT -5
Those are all interesting, thoughtful questions. Here are my (hopefully) useful replies.
1. I don't think there should be any fundamental problem switching from any mode to any other mode, at any time. There is no need for a "mother-may-I" type of functionality, or any need to wonder about levels of restrictiveness.
2. Because of (1), the only significant issue would be what to do with unsaved changes. I say, if you go from a less restrictive mode to a more restrictive one, and unsaved changes are present, you'd have to save them before changing modes. Obviously, EDIT can have unsaved changes, but so can VIEW. For VIEW, you're forced to do a SAVEAS, but still, changes could exist. As long as users don't lose data and are advised of important situations, I don't see any problem changing modes.
3. I kind of think that, as we are starting to describe MODE, it's NOT a profile setting. (Correct me if I am wrong.) It's just an operating choice.
NOW ... if you DID want MODE to be a Profile setting, then what that would mean is it describes the MODE that *would* be in effect IF you opened the file with a SELECT instead of EDIT/VIEW/BROWSE. Since you could change a MODE on the fly, establishing a "select-default" shouldn't hurt anything.
To answer your remaining questions:
4. "* EFT for a file contains MODE BROWSE; How does one EDIT the file? "
By using EDIT. MODE would only work if you opened via SELECT. This is another reason why you would need a Primary-command level of SELECT, which currently only has a FM line-command implementation.
5. "EDIT filename will override to BROWSE." YES, and we don't want to get into a "permissions game". If I say EDIT, then damn it, I want to EDIT.
6. "And MODE won't allow BROWSE -> EDIT". YES it will.
MODE serves two purposes:
(a) It's what I use to CHANGE the mode I am already in. Suppose I am editing and I have reached a stage where I have a "good" file that I don't want to change any FURTHER. At that point, I can say MODE BROWSSE so I can't alter it by accident.
(b) If I edit a file by mouse-clicking in FM, that defaults to a SELECT. What I do THAT, then the MODE will force the opening to happen as specified by its mode-type.
The only remaining question is, where will MODE "live"? Is it only on the EFT line? Is it a new PROFILE setting? Is it a just a new edit Primary command? All three?
Part of the answer is how ambitious you are. For max ambition, make a new Profile setting of MODE.
There would be a hierarchy of how the 'final' mode is determined.
(a) An explicit EDIT/VIEW/BROWSE is always honored, so it has highest priority, and then EFT and PROFILE settings are ignored.
(b) If a file is opened via SELECT, then EFT setting is honored if present, or else PROFILE MODE setting is honored. For old profiles without a MODE setting, you'd insert one at some point and default it with EDIT.
(c) Regardless of what mode you ended up with at the time you're ready to sit down and edit, you could always issue another MODE to change it if you wanted to.
Remember that the main purpose for MODE is to protect yourself from making accidental changes to valuable files. It's not intended to handcuff you or prevent you from getting your work done.
|
|
|
Post by Robert on Jul 12, 2023 18:37:14 GMT -5
===> IMPORTANT POINT
There are two use-cases where changing modes is involved:
1. You are in the middle of an EDIT, and you want to simply change the mode of the session - AT THE MOMENT - to Browse.
2. You want to change the default for how a file gets opened.
These are not the same things
Use-case (1) is a temporary change, while (2) is a permanent change.
How to distinguish them:
Make a temporary change to the Mode:
MODE VIEW
Make a permanent change to the Mode:
PROFILE MODE VIEW
p.s. Yes, I think that this should be the way all settings are handled. If you say EOL CRLF it ought to be temporary, but PRO EOL CRLF is permanent.
HOWEVER, I realize that would be a major change, and to be honest I haven't thought it through. It might not be feasible. And certainly not something to be attempted by tomorrow afternoon. :-))
|
|
|
Post by Stefan on Jul 13, 2023 7:18:14 GMT -5
Interesting discussions. FWIW - (probably not a lot).... Line numbers: Aside from COBOL (possibly not even then, but I never used it in an SPF context), who cares about line numbers on statements these days? The whole stmt numbering came about so that folks could sort their card decks after accidentally dropping them on the floor. Is numbering still relevant today? Is it perhaps used by source code management software, Endevor springs to mind (other systems are available :-)? MODE switching
I understand Robert's comment about the TWO use cases. In terms of use case (1), and as a user who always runs with AUTOSAVE ON NOPROMPT, I know that a habitual PFK-3/END to close a tab can cause changes to be unintentionally saved. Because we SAVE more often than we view, I always found that using the OFF or PROMPT options is annoying and quickly becomes habitual anyway and thus ineffective. I also habitually click on the FM entry (SELECT). Very, VERY, rarely do I start a tab with BROWSE or VIEW (can never remember the difference anyway). So I'm perhaps a good example of a user who'd benefit from the ability to switch mode - temporarily or always for certain files/filetypes. There was a question about - should data be saved before switching modes? If you save changes before switching to a more restrictive Mode, you defeat the purpose of the switch. Changes were saved. Maybe they were valid and a complete set, maybe not. If a user wishes to commit changes, BEFORE starting a more delicate operation on the same file, they can complete the EDIT as usual and then reopen the file in VIEW or BROWSE.
If they can't remember to do that, they won't remember to change MODEs either.
I think maybe the implementaion of the switch should NOT switch "MODE" within the current tab, but instead copy the text into a new tab and open that in the more restrictive mode. In its basic form, this could be achieved with a macro, but a "MODE" command would be neater. A manual technique I have used occasionally is to (1) Enter c/ on line 1 and (2) issue CUT <somename> ; CLIP (Note: The CLIP cmd could also be VIEW or BROWSE for the <somename> file in the CLIP directory.)
Clunky but effective.
As for permanently requiring a kind of 'read-only' access to a file, EFT could assign a suitable PROFILE or overide the normal profile with suitable settings which just sets the internal VIEW or BROWSE mode flag.
|
|
|
Post by Robert on Jul 13, 2023 8:57:01 GMT -5
===> My mistake, there's really only one use case.
Reason: When an EFT line has profile overrides (as I understand it) SPFLite creates a temporary copy of the original profile. So, if an EFT line had,
"*.abc.txt" = txt,EOL LF
then a temporary copy of profile TXT is built, and then its EOL setting is changed. Once a file using this modified profile is closed, the temporary file goes away, unsaved, and the original profile is untouched.
George, is that correct?
If so, then there is only one use case: a MODE command is always 'permanent'. If issued in a non-EFT edit session - or an EFT session with NO profile overrides, the MODE change is permanent.
If issued in an EFT session with profile overrides, it is temporary. Importantly, it can be treated AS IF a 'permanent' change to a temporary copy of a profile - one that is destined to be discarded.
Thus, there is only one use case. MODE is permanent, and there is NO need to distinguish MODE VIEW from PROFILE MODE VIEW.
Whew !
R
|
|
|
Post by George on Jul 13, 2023 9:34:04 GMT -5
OK - With the changes I'm doing right now, a tab has ONE set of Profile data - PERIOD. I've done away with the previous design which had multiple active Profiles possible at the same time. So when EFT overrides are done, they occur to the resident, single Profile set immediately after that set has been loaded from the CFG file. They are memory changes only and DO NOT alter the Profile permanently. Creating a hierarchy of who sets the mode is VERY problematic (and why I have always rejected hierarchical type proposals). Many of the routines are called in a variety of ways from various other routines. e.g. Asking the file Open routines to figure out where the MODE setting came from implies it also has access to all the other possible values for MODE and where each setting originated. Remember the 1st sentence above, there is 1 and 1 only Profile data area. There must be a way, let me think about it, without knowledge of the internal flow, all else is guesswork. What I'm hearing is: - MODE is added as a Profile option
- MODE command will always switch the mode AND it alters the Profile permanently (unless Profile is LOCKED)
- Any explicit open command (EDIT, VIEW, BROWSE overrides the Profile MODE entry AND overrides any EFT MODE override
- An FM SELECT (with whatever the FM DEFAULT specifies) will honor the Profile MODE, which may also be overridden by an EFT override. This is NOT considered an explicit EDIT, VIEW, BROWSE command
George
|
|
|
Post by Robert on Jul 13, 2023 11:09:28 GMT -5
I don't think a hierarchy was ever implied (not by me, anyway), so the fact that you are *certain* you don't want a hierarchy is totally fine with me.
I don't believe the open routines need to know *where* a MODE setting came from. All they need to know is *what* the MODE setting is.
I see your conclusions as correct, and we are in agreement.
One important point. I had forgotten about the DEFAULT FM command. Currently, this is considered to be a temporary setting, but in view of the changes you are implementing, I am wondering about its role at all.
DEFAULT defines what the SELECT action does. If someone wants the default for files with an EFT to be respected, then DEFAULT SELECT is a good choice. (It's the "default" for DEFAULT, as awkward as that sounds.)
If someone has set DEFAULT VIEW and clicks on a file that has an EFT override or a PROFILE MODE EDIT, what happens then? (Do we even want to think about it?)
Personally, I can tell you that I have absolutely never used this DEFAULT command. (If it got there because I asked for it, by all means please blame me.)
I believe the time has come to remove the DEFAULT command.
So, what takes the place of DEFAULT? If I click on a file name or use a SELECT command:
(a) the EFT mode override takes effect, if any
(b) or else the Profile mode setting takes effect, if any
(c) or else the SELECT/click is treated like EDIT
Do you agree?
R
|
|
|
Post by George on Jul 13, 2023 13:13:37 GMT -5
Robert: Yes FM DEFAULT should die, I've never used it, and I'm pretty sure it's unknown to most users. The only valid excuse for having it was for something like cleanup; set it to DELETE and you can delete files in FM by just selecting them.
DEFAULT will be deleted.
The routines DO need the source. Say a file has a Profile with MODE = BROWSE. Then an open for EDIT request comes in. If it's from an EDIT command, the EDIT wins. If it's from an FM SELECT, the BROWSE wins. So the source of the request IS needed.
This will be fun.
George
|
|
|
Post by Robert on Jul 13, 2023 14:08:55 GMT -5
I don't know if you can do this, but ...
You know how you have the command queue for SPF_POST_DO() so that once a macro is done, you have a list of commands to execute afterwards?
Maybe you could insert a MODE command into such a queue (maybe even the same one?) so that when a MODE override on EFT is found, you could stash the mode command into the queue, and process it once the edit session was up and running.
What happens if an EFT is invoked from EDIT/VIEW/BROWSE and it has a MODE command on it? When you use EDIT/VIEW/BROWSE, you *know* that EFT MODE is not supposed to be used, so at that point, delete the MODE override before you ever get (or need) to decide where it came from. At the time EDIT/VIEW/BROWSE is issued via a user command, you know where it came from.
Maybe a special "flag" to tell you 'where' isn't needed?
R
|
|