|
|
Post by Stefan on Jun 28, 2020 4:20:30 GMT -5
... where the cursor is located at the start of a primary command macro?
Hi Guys,
I have a macro which is invoked from the command line (as opposed to a line command macro)
I need to determine where in the file the user was when the macro started e.g. a kind-of .ZCSR or even cursor row & col.
I can obtain a line pointer to the top line on the current page using Get_TopScrn_Lptr.
But both Get_Csr_Lptr and Get_Csr_Col return 0, presumably because the macro is started from the command line, so the cursor isn't/wasn't in the 'data' area.
I haven't found a way to determine where the user was at the time a command line Macro starts. Am I missing something obvious (again)?
It would be perfect if, every time the user presses an 'attention' key (<PFn>, <ENTER>, <PAn>, etc) SPFLite saved the cursor position and provided a GET_xxx call so it can be obtained by a macro.
Perhaps best to implement a new "Get_xxx" call rather than change "Get_Csr_xxx" to provide backward compatibility in case folks rely on those showing 0 under some circumstances. Thanks.
|
|
|
|
Post by George on Jun 28, 2020 10:22:34 GMT -5
Just assign the macro to a key as a primary command.
If the key is pressed, the macro will be invoked, and Get_Csr_Lptr and Get_Csr_Col will return the correct values (Because you didn't need to move up to the Command line to enter the command)
Get_Csr_Lptr and Get_Csr_Col return the locations based on where the cursor was located when the Interrupt occurred.
George
|
|
|
|
Post by Stefan on Jul 3, 2020 9:04:55 GMT -5
Hi George,
That helps, thanks.
I'm trying to avoid SPFLite returning the display to a completely irrelevant area of the file whenever I press <ENTER> AFTER scrolling the screen using cursor keys or the mouse wheel. For example, SPFLite will jump back to wherever the first "D" line command was entered, while I might be working 100s of lines lower down in the file by then. If I can just persuade it to keep me on the same page in those circumstances, that would be a good start. More accurate, let alone any 'smart' cursor positioning is probably beyond the scope of the available tools, but keeping it near where I was working will help.
I've mapped an experimental <ENTER> key as
(SaveCursor)(Home)(SetInsert)[SNcsr;](RestoreInsert)(RestoreCursor)(Enter)
Macro SNcsr gets correct values for cursor line and column and top of page. Any other existing primary command still executes after the macro as intended. I don't mind where that leaves the display because I expect it to change. But I don't expect the display to jump around if I only pressed <ENTER> to commit a few typed changes and maybe a handful of line commands.
It's a start. As I don't use 'user' lines for anything, I may use that 'flag' to discreetly high-lite the current cursor line.
|
|
|
|
Post by George on Jul 3, 2020 16:22:38 GMT -5
Stefan: I realize that when you do a few line commands, scroll elsewhere and do some more stuff and then press Enter, that the cursor positioning logic may scroll you back to some point you may no longer care about, but unless you have some miraculous algorithm, I'm not sure any default logic can cope with what you're after, not without messing up "normal" positioning logic.
I, like you, sometimes end up where I don't want to be.
I'm afraid the only answer is to hit Enter (or some other PFK key) more often so that interactions can occur before you go off scrolling somewhere else in the file.
I'm always open to other suggestions.
George
|
|
|
|
Post by Stefan on Jul 7, 2020 8:42:19 GMT -5
Hi George,
Fiddling about with this, I found that the issue is caused by just a few line commands. Note, I'm not talking about the effect Primary commands have on screen positioning, only the processing of line commands.
SPFLite appears to maintain the ToP at the same LINE NUMBER as it was before the <enter> key was pressed, UNLESS one of line commands requires the user to further interact with it. Perfectly sensible. My issue is that the 'UNLESS' category includes some line commands that perhaps shouldn't be there. The line commands I've identified thus far that cause an 'unexpected' backward jump in the display are D/DD, N, TJ/TJJ, J/JJ and G,GG.
We could argue whether all of these require the user to be brought back to them, but I would single out D/DD as the biggest culprit.
Example:
I R2 repeat line 2 and, some time later when I'm 300 lines away, press <Enter>. The display remains where it is (except for a 2 line difference in ToP).
Do the same but Delete line 2 or iNsert a blank line after line 2 and the display jumps all the way back to line 2.
I don't see why D or N warrants my retrospective attention, any more than R or CC..CC...A or any other line command not mentioned above.
I think any user casually inserting or deleting a line or 3 here or there, or indeed issuing ANY line command, will press <Enter> immediately if they were concerned that the command may not do what they want or they intended to do more in that area. But if they abandon that change by moving on, I think that amounts to an implied 'that's done, don't bring me back here'. In the case of several Delete line commands, only the first gets that level of focus, the others are effectively 'done and lost' anyway.
On a related but less important note, as stated above, SPFLite appears to keep ToP at the same LINE NUMBER as it was before the <enter> key was pressed.
But line commands that occur earlier in the file than the current Top of Page (ToP) often change the number of lines between the start of the file and the current ToP.
So if, after processing the line commands, there are more or fewer lines between the start of the file and the ToP, the LINE NUMBER at the 'new' ToP will be the same as before, but it will refer to a different line. Whilst not ideal, I'm OK with that, because unless I insert, delete or combine dozens of lines, the display is still in the same ball park.
But if SPFLite maintained a single 'net' count variable of lines logically added or removed by the line command activity 'above' ToP, it could adjust the new ToP LINE NUMBER accordingly.
|
|
|
|
Post by George on Jul 7, 2020 10:35:18 GMT -5
Stefan: The problem is basically due to differences in capabilities between the old ISPF style, and the SPFLite style. Everything in ISPF was driven by the concept of the Attention. (Enter or PFK key). When an Attention occurred, line commands were performed, followed by Primary commands. Nice, simple and clean-cut. And the basic design of SPFLite way, way back was built around the ISPF style.
And then SPFLite introduced auto-scrolling, via the keyboard and/or the mouse-wheel. So now it became possible to enter line commands and then scroll and enter more line commands and finally, many line commands later, press Enter. Throw in line command Macros and all the possible actions they can perform, and it becomes ridiculously complicated.
The TopScrn location is weirder, it is not simply a line number, the actual line itself is flagged as BEING the top line. This is needed in order to survive the process of Excluding and un-Excluding lines (which are totally re-built on any change to excluded line status).
Line commands themselves are also split into Immediate and Delayed categories. Some like Immediate (I, N, R, D) and done in an early phase of line command processing, the rest are done later. And every one of them must spend time constantly updating the line pointers of all the pending commands still awaiting processing.
Anyway, I tried as a test altering D/DD to remove the forced positioning, it works OK for some aspects, but also messes up CSR scrolling, so I would be swapping one 'problem' for yet another. I will leave this change in D/DD in place for the next release and we'll see what other comments it generates.
George
|
|
|
|
Post by Stefan on Aug 3, 2020 9:25:25 GMT -5
Hi George,
Thank You for v20191. Great stuff!
Thanks also for the change to the Delete line command. A definite improvement.
|
|
