|
Post by Robert on Jan 22, 2024 16:16:31 GMT -5
With the availability of SPFLite beta 24.021, I started looking around to see the impact of this beta release, and looking at the General Options GUI, I noticed the entry Check For SPFLite Update Interval. When I did a manual check, it said I was up to date, and when I checked the last prod release 23.313, it said the same thing.
What I am wondering about is whether we could be more precise about this checking process.
First, is it possible for the code to "know" if it's a beta release? If you look at the Title Bar, all the current beta says is, SPFLite(v3.0.24021)
If this were a production release that had been made on that same date, you'd see exactly the same thing. I wish this worked a little differently. How so?
(a) Devise a means by which your code "knows" if it's a beta version or not.
(b) In the Windows Title Bar, add "BETA" to it, so it's clear that a beta is running. Like this: SPFLite BETA(v3.0.24021)
Second, when a user clicks on the Check Now button, you would check both for the most recent prod version and the most recent beta, and report on both statuses. Now, sometime when you release prod, you don't always show a download link for betas, since the prod would be newer than any existing beta. How you would handle that is up to you. Do you have a way to download "old" beta? I don't recall ever trying to do that, but hey, maybe someone would want to for some reason?
Well, that's the idea. Since you are so close to a new prod release, I wouldn't hold it up just for this, but maybe it's something you could look into for the future.
R
|
|
|
Post by Robert on Jan 20, 2024 16:02:40 GMT -5
That seems reasonable
|
|
|
Post by Robert on Jan 20, 2024 13:01:06 GMT -5
The only trick would be managing the transition. Maybe you could keep the existing UI, but any time a profile is added or changed, you would check to see if it was higher than the current global level, and if so, you'd change the global level to reflect the new maximum level.
|
|
|
Post by Robert on Jan 19, 2024 10:00:10 GMT -5
Well, I just went in and manually set all of them to UNDO 25, took less time than I thought. I see that with recent changes, every profile now has its AUTONAME set to the name of the Profile, instead of NONE. If you then go and edit profile ABC that never had an AUTO file, you get an error, like ABC.AUTO does not exist. So, you are forced to change it to NONE before you can change anything else. Not a real big deal, but was just a little surprised.
R
|
|
|
Post by Robert on Jan 18, 2024 12:47:02 GMT -5
George,
I had two reasons for the prior comments that prompted this Outreach thread. The first was to suggest a change to the architecture that would hopefully make it more resilient and less vulnerable to bugs. The second was when I thought about my own use of UNDO in profiles.
I must confess, I have no idea what all the UNDO levels are in every profile I have. I'd have to painstakingly go open up every profile and check each one of them. To be honest, I don't think much about undo levels. All I want to do is UNDO when I need to. But, since I am the same person, with the same likelihood of making typing errors - regardless of what file type I happen to be editing at any given moment - the ability to fine-tune the UNDO level based on file type is not a big seller for me. I basically want the max for every file, all the time.
But, I could do that manually, if I really wanted to. It might take me 20 minutes to open up and edit every one of them, but it's not a big deal. So I can fix that myself without any code impact on your part.
What I really want more than altering the UNDO level is a change to the overall UNDO structure and architecture. It has always seemed a very high overhead feature. So, if I have one file with 25 undo levels, SPFLite is going to open up 4 x 25 = 100 temporary undo files. Wow, that's a lot. Then, if every profile has 25 undo levels, it's 100 temp files for every open file. A high overhead, but if you want insurance against editing errors, all insurance comes at a cost.
Now, I know you can't rewrite your whole code, even if doing so had advantages, because it's bridge too far. It's just too hard. But, SPFLite doesn't live in a vacuum. We all have many editing choices. For example, when I really need to edit free-form documentation text, I use NotePad++ which I am quite spoiled by. It's undo feature is always active, needs no special user intervention to enable, and essentially has unlimited levels. And, you can undo/redo down to the keystroke level. They allow that because they in turn use an open-source edit engine and add the UI on top of it themselves.
I am not unreasonable, and I don't expect that from you. But what I find frustrating is, even when UNDO is enabled, it happens too often that I try to UNDO something and can't. Instead, I get that message about 'no more undo levels'. There is a very specific "UNDO boundary" built into the process, and if you catch it at the wrong time where you change something that is not within some kind of "editing interval", you can't undo it. For me, I have to be very careful what I do, because otherwise I can get in that "UNDO limbo" where I change something and can't undo it, and then my only recourse is a CANCEL.
I don't want to rag on you, because I know you've just been through a very long and difficult debugging session on UNDO, and now that it seems to work, I don't want you to think I am anything but appreciative about all the work you've done. But to be honest, UNDO has never really worked what I would call "well". It sort of works, and if you work within its limitations, it is certainly useful. But there have always been problems with it. I just wish it could be done differently.
R
|
|
|
Post by Robert on Jan 18, 2024 9:44:07 GMT -5
Not to push on this concept, but IF you had an inkling of trying it, one way could be to do a scan of all the profiles, and set a (hidden) global UNDO level to the maximum of any Profile entry. So, if one had 10 and the rest had 5, everything would be treated as 10. It wouldn't require any UI interface changes to do it.
R
|
|
|
Post by Robert on Jan 17, 2024 12:11:14 GMT -5
George: "Basically, if all the profiles used had the same # of undos - no problem."
That suggests that maybe the number of UNDO levels ought to be a global option value, and not something that is specified in a Profile. That way, the number of levels would have to match.
Thoughts?
R
|
|
|
Post by Robert on Jan 16, 2024 16:37:22 GMT -5
I believe there would be legal impediments for me to order alcohol across an international border. But I will send some virtually via good wishes.
R
|
|
|
Post by Robert on Jan 16, 2024 14:19:00 GMT -5
YAY !!!
Everything works, NO ERRORS !
Whew.
R
|
|
|
Post by Robert on Jan 16, 2024 14:10:10 GMT -5
George, I will test this ASAP. I was just wondering, could all the UNDO issues have been prevented if you forced all profiles to have a minimum UNDO level of 1, even if they say 0 ?
Maybe even support a larger default UNDO level? What does it buy the user to have no UNDO level? Is there any advantage to it?
R
|
|
|
Post by Robert on Jan 16, 2024 12:33:18 GMT -5
I was out grocery shopping, just got back. It's 10F here (about -12C), not much fun for going out.
R
We're not quite that bad, it's -7C (about 19F) and sunny.
G.
|
|
|
Post by Robert on Jan 16, 2024 9:39:32 GMT -5
Well, again, the point of the log is to help YOU. Do you find the log in its current form helps - that is, is it providing you with information you didn't have before? Whatever the log ends up being, it will be driven by your needs, not ours.
R
|
|
|
Post by Robert on Jan 15, 2024 18:54:22 GMT -5
I see that you are also logging FM commands. When I put FCLIP on line 2 of the FM list, you logged this as:
18:43:44 P Start: FCLIP 2
But from the log, there is no way to know this is an FM command. And in particular, this was a macro issued as an FM line command, not a primary command.
I can see as this gets used, the need for a lot more potential logging information might come to light. Besides FM vs. edit, you might have edit vs. browse, or which edit window was in use, etc. etc.
Maybe you want to log messages and popups that occur, so you know when those events happen.
I suspect this is a tip-of-the-iceberg / can of worms idea. But, you seem to like the idea, so pop open a fresh can of worms, fire up the barbie, and let's chow down :-)))
We are on the start of a new learning curve. Fasten your seatbelts, matey.
R
|
|
|
Post by Robert on Jan 15, 2024 18:28:04 GMT -5
Wow, George, I didn't think you could knock this out so fast. A couple questions:
1. I see you didn't adopt the serial number idea. Maybe that wasn't necessary. I think other users need to weigh in on the idea.
2. I was thinking, suppose someone had an issue where they needed your help, and they sent YOU a command log. Is the log in its current form something YOU could use to replicate an issue? At present, the log is mainly human-readable data. And, potentially, there could be a LOT data to wade through.
Could the log's format be revised somehow so that that it could be "executed"? If so, it might need more explicit information than I originally conceived of. Some kind of "command log execute" command? For such a thing to be possible, the log needs to be machine-readable and explicit enough to accurately reconstruct each step of the process. Remember, it would be YOU that needs to reconstruct it. What would help YOU?
I don't have strong feelings about this, it's just a general question.
I really hope other users pipe in and comment on this.
This is a nice surprise, George. Thanks.
R
|
|
|
Post by Robert on Jan 14, 2024 17:17:09 GMT -5
OK, I emailed it off to you. Was able to reproduce the incident 3 times consistently.
R
|
|