Stefan: Yes large Inserts/Deletes above the 'current' screen mess things up, and I'm afraid that's the way it stays. As to Primary commands, I agree, I don't see that needs testing. As for line macros, might be worth it, they are executed
prior to regular line commands. They should also be ignored.
George
Hi George,
Three comments about your discussion with Robert, please...
(1) Re: the above quote, I think we are slightly at cross purposes. What I meant was - "Do we need to test the cursor effect created when a Macro issues a line command as part of its processing?" Potentially it will rely on the cursor placement performed by that instruction. Would the "Reset...Lcmd" Option suppress that too?
Actual Line macros should be fine as there can't be any other line commands issued in the same 'transaction'. This kind of implies that there's little reason for the user to depart from the current 'page' anyway.
(2) IF there is a choice between accurate page positioning and allowing the line commands on the current page to still operate normally, I'll take accurate positioning all day long.
(3) I should like to ask this, with a view to perhaps simplifying the entire process. My 'clunky' solution works well, except for the fact that it is unaware of the 'environment' in which it executes. Therefore it does suffer from some predictable but daft problems. But its advantage over the changes you've tried to incorporate thus far, is that there is no need to interfere at all with the any line command or existing cursor positioning logic.
What if... When the 'Reset...Lcmd' Option is set, you implemented the sequence of instructions I simulate with my code. The steps would mean that...
(1) When you receive the <ENTER> attention for the EDIT window (ie. not FM or a dialog window) and cursor is in the line-command or text/data area, you PRETEND (i.e. internally do the processing for the following)
a) that the user placed a label .pc on the current line (I used the following line because if user types 'LCMD' <ENTER>, I can't label the current line without losing the LCMD)
b) that the user placed a label .pt on the line at the top of the current page
c) You set a flag to trigger 'post processing' after the line commands
Step (1a): If using 'following' line, step (1a) should include a test to ensure there IS a following line that can be labeled (ie. not Bottom Of Data).
Steps (1a) and (1b): Should include logic to determine if these lines already have labels which should be saved and restored later as part of (2) below
(2) When all line commands have been processed normally, ie. before you go on to Primary command processing, you check 'post processing' flag. If it is set, you do the following
a) Clear the 'post processing' flag
b) Add the PBASIC equivalent of this code...
' Set Top of Page and determine cursor row/line
Set_TopScrn_Lptr(Get_Lptr(".pt")) ' Place Page as per previous ToP
csrLptr = Get_Lptr(".pc") ' Get pointer to cursor line
csrLptr = Get_Next_LPtr(csrLptr,+1,"DATA") ' NOTE: only needed if you used 'current line' in (1a)
' Note: If the lines had labels before, restore those label(s) rather than RESET them
SPF_CMD("RESET LABEL .pc .pc") ' Remove the line labels
SPF_CMD("RESET LABEL .pt .pt")
' Determine cursor column position and place the cursor
linData = Get_Line$(csrLptr) ' Check indent on cursor line
csrCol = Verify(linData," ") ' Find first non-blank char or 0
IF csrCol = 0 AND csrLptr > 2 THEN ' If line is blank ...
newLptr = Get_Next_LPtr(csrLptr,-1,"DATA") ' .. try the previous line
linData = Get_Line$(newLptr)
csrCol = Verify(linData," ")
ENDIF
IF csrCol = 0 AND csrLptr < Get_Last_Lptr - 1 THEN ' If previous line is blank ...
newLptr = Get_Next_LPtr(csrLptr,+1,"DATA") ' .. try the following line
linData = Get_Line$(newLptr)
csrCol = Verify(linData," ")
ENDIF
Set_Csr(csrLptr,MAX(csrCol,1)) ' Place cursor as required
Advantages:
- All new coding is external to existing logic - less risk to an already complex area and less testing required
- Approach is a 'wrap-around' to line command processing and will work with existing and future line commands.
- Your internal code IS aware of the environment, so no messy FM or dialog screens, easy avoidance of clashes of .pt .pc labeled lines with existing label or LCmds.
- Because you 'pretend' that the user labeled the Cursor and ToP lines, you don't interfere with any existing line commands on those lines
(although you might 'lose' any labels already there, but you could temporarily save/restore existing labels (if any) on those lines as part of the 'pretend' code)
- Avoids potential interference with line commands issued from within Macros, because all line commands work exactly as they do normally.
- It uses the fact the line labels ALWAYS stick with the same line (as in line content) and thus tracking the ToP and Cursor line location already happens correctly
Any help?