|
|
Post by Clive L on Feb 2, 2024 17:41:57 GMT -5
I'm not sure if I'm missing something, but I have the following issue:
I have recently upgraded to version 3.0.24026 from 3.0.23088. Since doing so, if I issue an Edit command (either from File Manager or within an already edited file, and the named file doesn't already exist in the folder), I just get an error message telling me the file doesn't exist and no other action.
The old version works fine. It just puts me into a new file with the selected name and allows me to edit it.
Is this a bug or have I missed some new parm required in these circumstances? I can't see anything that suggests so. The most likely thing I can see is the EFT mods in the Changelogs
|
|
|
|
Post by Robert on Feb 2, 2024 18:09:55 GMT -5
Clive, as best as I can tell, the last beta where you could issue an EDIT for a non-existing file and have it successfully edit as a "new" file was 23.154, which is about July 1 of 2023. After that, you will get the non-existing file error. Personally, I think it is now doing what it should do. I believe IBM ISPF won't edit a file if it doesn't exist. But, I haven't used ISPF in a long time so I could be wrong about that.
Of course, if you want to edit a new file, you can click on NEW.
HOWEVER, George, if you read the HELP EDIT, it doesn't appear that the Help and the current behavior of EDIT are in agreement. IIRC, the original way SPFLite worked with EDIT nonexisting-file was to create a file. That's what happens in 23.154, but not afterwards. And, I don't recall any mention in the forum that this behavior was going to be changed. The usual term for this is a "slipstream change", when a change is added without telling anyone.
Comments?
|
|
|
|
Post by Clive L on Feb 2, 2024 18:38:52 GMT -5
Ok thanks Robert. NEW does the job (although SAVEAS, specifying a filename once I'm in my new file just puts me into a windows dialogue to specify the filename - which it pre-fills but otherwise acts as though I hadn't specified the filename.
If having saved the file I issue a SAVEAS (with a different filename) it does it directly, changing the name in the currently edited tab and retaining the initial saved file.
Incidentally, ISPF does allow you to edit a file that doesn't exist
|
|
|
|
Post by George on Feb 3, 2024 11:21:02 GMT -5
Clive: Robert:
Yes, it seems to have disappeared, not intentionally. The whole area of handling files was re-written a couple of releases ago to remove one of our 'better ideas' which ended up being a not-so-better-idea. That change itself went well, this is the 1st fallout reported from it.
It will get corrected, but fixing it has shown up weakness in the cross-tab message handling, so I'm going to tackle cleaning that up as well.
George
|
|
|
|
Post by Robert on Feb 4, 2024 14:13:02 GMT -5
George, I wanted to mention that when I did testing on this issue, for the version 23.154 where you can still say EDIT unknown-file, if you do this and you find that there is no file currently existing, I am tempted to just say CANCEL and (presumably) enter the "correct" name if there is one, and try editing again. But, if I say CANCEL in this scenario, SPFLite (up to that version) will create a new, zero-length file to be editing. But I say CANCEL and never saved the file, it seems like this newly-created empty file should go away.
Or, perhaps the whole scenario is unusual enough that maybe what is called for is a popup? Maybe something like this:
File "unknown-file" does not exist. Do you want to cancel the EDIT, or create and edit a new empty file?
[Cancel] [Create and Edit]
What do you think? Personally, it is very rare that I would ever say EDIT filename when there was no such file.
R
|
|
|
|
Post by George on Feb 4, 2024 14:18:46 GMT -5
Robert: Well, I just posted a new Beta with the fix.
If you don't want the file, don't say CANCEL - use CANCEL DEL to also delete the file.
I agree, this is very rare, the error has been there for quite a while.
George
|
|
|
|
Post by Robert on Feb 4, 2024 20:12:01 GMT -5
Right, only thing is I was so surprised by this behavior, I forgot about the CAN DEL, and that is weird, because I am the one that told you to support CAN DEL in the first place. I don't know if extra hand-holding is called for, but something about this just rubs me the wrong way. Like, the way you changed things was correct, and it didn't need to be fixed. Or maybe, what it should have been was, EDIT unknown-name NEW, or something.
I feel like, if you edit an unknown name, maybe you should allow it, but somehow "remember" that you created it out of thin air, so that the user would actually have to do something, like create some lines, or say SAVE, or - you know - SOMETHING. Do something other than nothing. Just so it doesn't create an empty file.
I hope other users would pipe in and say a few syllables about this. What do y'all think is the right thing here? I couldn't swear to it in court, but something just doesn't seem right.
Am I nuts, or is there something to this?
R
|
|
|
|
Post by George on Feb 5, 2024 10:57:31 GMT -5
Robert: This is not worth a lot of bother. I can't even remember the last time I actually said "EDIT filename" as a command. My personal preference would be to simply reject it, but we put it in because good old ISPF did it that way. And if we changed, somebody would for sure go "Wah! I want it".
George
|
|
|
|
Post by Robert on Feb 5, 2024 11:25:31 GMT -5
Just looked at 24.035 beta. I see it now produces the message, File did not exist, created as an empty file. That is a good solution. Perhaps this just calls for a little update to the Help for EDIT. You could make note that this message will appear if 'filename' doesn't exist, and remind users that they could say CANCEL DELETE if they used the wrong name.
R
|
|
|
|
Post by George on Feb 5, 2024 12:46:22 GMT -5
Robert: The message had always been there, but somewhere along the way, it just didn't make it out to the screen. The changes in the last Beta included a revamp of how cross-tab messages are handled. Some extra words in the Help are still a good idea.
George
|
|
|
|
Post by Clive L on Feb 8, 2024 19:39:04 GMT -5
A supplemental issue ... Since upgrading to 3.0.24026 my colorization files no longer appear to do anything. Editing a COBOL program for example, running 3.0.23088 using the identical colorization file, and with the Profile information looking the same in both versions, the older release works fine with the selected colors, the new one does no highlighting
|
|
|
|
Post by George on Feb 9, 2024 11:24:07 GMT -5
Clive: Reported. Try the latest Beta, there's a fix in there for the problem.
George
|
|
|
|
Post by Stefan on Feb 9, 2024 12:48:31 GMT -5
A supplemental issue ... Since upgrading to 3.0.24026 my colorization files no longer appear to do anything. Editing a COBOL program for example, running 3.0.23088 using the identical colorization file, and with the Profile information looking the same in both versions, the older release works fine with the selected colors, the new one does no highlighting Clive,
Take a look in the PROFILE and examine the AUTONAME value. This setting is relatively new and I think AUTONAME defaulted to NONE initially, but I believe George has fixed that subsequently. HELP AUTONAME should provide clarity.
|
|
|
|
Post by Robert on Feb 9, 2024 14:38:40 GMT -5
Actually, I believe initially defaulted to the file extension. So if you had a .macro file it would default to an autoname of MACRO, but since the real auto file was probably BAS.AUTO, your colorization wouldn't work. I think George did apply some kind of fix for this, but it's been several weeks so the brain cells aren't cooperating.
George, could you provide some insight here?
R
|
|
|
|
Post by George on Feb 9, 2024 15:13:33 GMT -5
Robert: Well. AUTONAME defaults to NONE, which means the AUTO file is = to the Profile name.
Which is the same as AUTOFILE = * (And I don't remember why we added the *, isn't NONE sufficient?)
Otherwise, the AUTOFILE name is whatever is specified, and it better exist.
George
|
|
