|
Post by Robert on Feb 10, 2024 11:38:10 GMT -5
George, the decision point "Same exact version/Beta status" is what I have an issue with. If you read about "Only 1 SPFLite running" in the Options - General Help, this decision point is not documented.
I believe you changed this logic some time back, and didn't make a fuss about it, not that I recall. I feel that what is currently implemented is misleading. We can check "Only 1 SPFLite running", but there can still be more than one, as long as each executable has a unique version and beta status.
Basically, your logic effectively has an option like this:
[x] Allow multiple unique SPFLite instances to run
Only, the "[x]" is permanently turned on and we can't disable it. I would disable it, if I could.
I wish this worked differently. Here is a proposed change. Let's say the question were changed from a checkbox to a dropdown box. Then, there would be a new entry like this:
Allow multiple instances of SPFLite to run [dropdown]
In the dropdown, there would be 3 options: No Yes Yes, for unique SPFLite versions
This would allow users to control how this gets handled. Here, "versions" would be documented to mean the combination of version number and beta status. However, in practical terms, beta status doesn't really need to be checked for, as long as you never create a beta version and a prod version with the same version number. So far, I don't think you've ever done that, right?
R
|
|
|
Post by Robert on Feb 9, 2024 17:40:19 GMT -5
Can you tell me if the precise process how single vs. multiple instance thing is handled? You now tried to explain it, and yet I still don't understand. The thing you say you want to avoid, I would avoid too. There seems to be a fundamental misunderstanding here.
Could you spell this out for us in plain English? What is going on seems vague, and I find it disconcerting.
R
|
|
|
Post by Robert on Feb 9, 2024 15:53:24 GMT -5
George, I would like to offer some well-meaning advice. I believe that your current test for an existing SPFLite running is being too 'precise'. I think the correct thing to do is to see if ANY version of SPFLite - beta or prod - is running, then that satisfies the test. Version numbers and beta/non-beta should not be part of the test.
That is the safest way to do it.
R
|
|
|
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 Robert on Feb 9, 2024 10:26:36 GMT -5
I thought that when you open using windows file manager, the "context entry" for SPFLite has a fixed EXE name, which is "the" production name of it, not any beta which might exist. For me, I have dozens of betas in the Program Files folder, but when I open a text file like you did, I get the prod version 24.026.
Which version do you get when you do this?
R ===> I see that you do things differently than I do. There is a thing George made to set up a registry entry, so that you can see "Open with SPFLite" as a context entry (without the 2 suffix), which is different than you do. You got your entry the 'hard way' by first doing an Open With, then (at some point) locating SPFLite2.exe in Program Files (x86) then picking the EXE.
I re-tried doing it your way, and I only get one EXE running, not two. Something doesn't add up here.
|
|
|
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 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 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 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 Robert on Jan 26, 2024 15:16:53 GMT -5
You were worried about bugs. Thus isn't a bug. Chill, George. It's all good.
|
|
|
Post by Robert on Jan 26, 2024 12:54:04 GMT -5
FYI the stand-alone change log for 24.026 doesn't mention the new (CmdLog) function. It *is* documented in the Help doc.
R
|
|
|
Post by Robert on Jan 23, 2024 23:25:07 GMT -5
George,
Since you posted the above 9 hours ago, I have been thinking about your release process, that 4-page document. Have you ever considered a "build script"? Unix developers have long used a "make" script and the Unix "make" utility to create builds. If you could use or adapt a make-like strategy, it might simplify your build process. Sometimes people create their own home-grown build systems, when an off-the-shelf "make" utility doesn't suit their needs.
Imagine your 4-page document. Now, think about what it would take to automate each step of the process. Suppose you could write some kind of automation tools, and put them into a script of some kind. There might have to be "exit points" where you had to do some steps manually and there was no good way to automate them. But, suppose even SOME of your process could be automated. If so, that could take a lot of the pain out producing new releases.
I don't know your internal workload, so this is just wild-@$$ guessing here, but I have always been a big fan of automation. Yes, you might have to write some of your own tools, and that would be work, but the effort would be WELL worth if, if you could pull it off. AND, you certainly have an incentive to make it work, because when you were done, it would reduce your work on a long-term basis, and it would help remove points where things might go wrong if you ever forgot something.
Just a thought.
R
|
|
|
Post by Robert on Jan 23, 2024 11:34:26 GMT -5
Just checked out 24.023, it looks fine. (I thought for sure you decided against it.)
R
|
|
|
Post by Robert on Jan 22, 2024 17:05:10 GMT -5
Not if you have to change something 8 times. If it were me, I'd conditionally #include the string(s) involved, but you have made this elaborate enough that it means this is the end of the story.
|
|
|
Post by Robert on Jan 22, 2024 16:44:14 GMT -5
Well, the only thing is, your current advise is to download the beta in the prod directory. Depending on how people run them, there could be some confusion. Yes, betas are transient, and I don't want to overly complicate this. You have enough problems. But, what about the first part? Can you identify an SPFLite exe as "BETA" and show it on the Title bar?
R
|
|