|
|
Post by mueh on May 2, 2023 10:30:10 GMT -5
George: When testing Roberts Pen anomaly is used a key mappped to (Pen/Navy)(Right) to color column by column . This worked up to 2.7.23056 . It crashes or colors only on first key hit since v3.0.23088 . SPFLite V(3.0.23122) @ 2023-05-02 16:21 SPFLite has encountered an execution exception (C0000005) Last Interactions were: K=ENTER P=res color K=DOWN K=DOWN K=DOWN K=DOWN K=LEFT K=LEFT K=PEN Module Back Trace:  As i can see you made correction in v3.0.23088 * Minor correction to the (LowerCase) primitive. It was not checking for an active Marked area before proceeding. If i change the key to undocumented CMark... (CMarkRight)(Pen/Navy)(Right) there is no problem . If it is required to mark now area it should get documented under Example of using highlighting pens It's easy to highlight text. You will have to establish a mapping for the (Pen*) functions. Here is a suggested mapping you may find useful. As always, you are free to map these any way you wish: Ctrl-Shift-R = (Pen/Red) Ctrl-Shift-B = (Pen/Blue) Ctrl-Shift-G = (Pen/Green) Ctrl-Shift-Y = (Pen/Yellow) Ctrl-Shift-S = (Pen/Std) and maybe code added in krPenCommon IF ISFALSE IsMarkActive THEN DoBeep: EXIT METHOD and mybe PT code (i'm not using) Thanks |
|
|
|
Post by George on May 2, 2023 12:01:56 GMT -5
MUEH: Yes I remember all this. There used to be a small fudge (originally requested by Robert) that basically pretended the cursor location was marked if the command required it. Don't remember the details now, but to solve some other problem, that was removed and the CMarkxxx primitives were created then to replace it.
No Doc. is just forgetfullness on my part, I'll correct that. And the Pen functions should not proceed if nothing is marked. I'll try and get this all cleaned up. These little convenience fudges over the years come back to haunt us.
George
P.S.
I setup the (CMarkRight)(Pen/color)(Right) on a key, works really well, Much easier than separate marking and coloring.
|
|
|
|
Post by Robert on May 2, 2023 12:12:24 GMT -5
The fudge was intended to remove the requirement to highlight a single character. There were not many details. The main point was that using the mouse to highlight a single character is quite difficult to do (it still is). To use a keyboard primitive on a single position, when it was supposed to apply to a highlighted area, SPFLite was altered so that the current cursor was *assumed* to be highlighted if no other highlighting was present.
In practice, this made coloring or changing case on a single letter was much easier. Evidently, over time, so much has changed that this fudge has become a problem to retain. That is regrettable, but oh well. The new CMarkXXX functions were added to provide an easy way to highlight one position the "legal" way, so that fudge isn't needed any more, except that to take advantage of it, most key mappings like colors and case changes now have to be updated to include the new CMark stuff.
|
|
|
|
Post by George on May 2, 2023 12:17:20 GMT -5
Robert: Yes, a bit of time to update some key maps, but the (CMarkRight)(Pen/Blue)(Right) combination is very handy. Try it. Simply replace your current (Pen/Blue) key. (Or whatever color you like)
George
|
|
|
|
Post by Robert on May 2, 2023 13:56:09 GMT -5
I was puzzled by the (Right) function in your example. Turns out there is (yet) more to the story than that.
Some functions already move right after running, such as (UpperCase). Others, like (Pen/Blue), do not, and need the (Right) to make them more consistent with functions like (UpperCase). This inconsistency in the behavior of functions that take highlighted text is regrettable.
I suspect that the correct action should have always been to move to the right once the function's main action is completed. Perhaps a survey of such primitive functions could be undertaken to see what the "post-function cursor movement" is in each case, and make it consistent one way or another, either moving or not moving, as long as they are all the same.
===> Just to make it clear:
While I believe being consistent is, in general, a good thing, I don't want my remarks above to be taken as a suggestion to change the code. Even if not all of these functions are "consistent" per se, the workaround is to just live within how they work, and map the keys accordingly. Since a workaround exists, there is no real demand to change the functions.
I feel that I have an obligation to point out when the code is acting incorrectly, because it affects all users, and I would like to continue doing that. But it seems clear that I shouldn't be making suggestions for changes any more. It doesn't usually end well, and that's not something I want. And I don't want to suggest what amounts to make-work when your heart isn't in it.
|
|
|
|
Post by George on May 3, 2023 9:25:27 GMT -5
Robert: I think 'correcting' this should be left alone. More users probably have custom key maps than they would, say, macros. But changing basic primitive processing is almost certainly going to impact users.
And besides, we'd never get agreement on what IS the correct way to handle things. I'm sure no single 'leave/advance' the cursor would work for all primitives. Then we'd have a mixture of - these primitives DO - these primitives DON'T. Very likely to get ugly.
George
|
|
