|
|
Post by Stefan on Jun 17, 2024 13:47:31 GMT -5
George,
Observed in v3.1.24168beta
In an attempt to separate my files again after MEDIT put them all together as one - see previous, I used REPLACE <filename> to re-populate the individual files. I also used MM....MM line commands to select the lines I needed for each file.
I noted 2 things....
a) The primary command of the format REPLACE <filename> ignores the <filename> argument and always pops up a Windows selection dialog.
b) The use of MM....MM is recognised and the correct lines are written to the selected fiename, but the lines are not deleted from the current edit session. Effectively, the MM...MM sequence behaves like a CC...CC sequence.
|
|
|
|
Post by George on Jun 17, 2024 14:02:30 GMT -5
Stefan: Actually, I spotted this Create/Replace thing this AM myself, just hadn't got to it.
The MEdit problem concerns me more, the C/R problem is certainly a trivial one.
George
[UPDATE]
Create/Replace - both problems - corrected.
[/UPDATE]
|
|
|
|
Post by Robert on Jun 17, 2024 15:12:07 GMT -5
Stefan,
What MM does in this case is part of a pattern when SPFLite was first being developed. For instance, you can COPY an external file into an edit, but you can't MOVE a file in the same way, even though ISPF supports this. The reason that was done is because the MOVE immediately deletes the source file in question, even if (perhaps) you make some mistake in the edit session and have to start over. In a scenario like that, you would have lost the MOVE'd file. In the name of safety, SPFLite doesn't allow that, so you're protected against accidental data loss.
I believe the MM behavior here is in the same vein. I believe SPFLite simply treats M/MM as C/CC in this context. I would call this intended behavior, not a bug.
R
|
|
|
|
Post by George on Jun 17, 2024 15:40:40 GMT -5
Robert: No MM does delete the lnes after a successful write of the data. Always did, this was a bug in the Beta.
George
|
|
