|
|
Post by Stefan on Oct 23, 2022 4:12:36 GMT -5
SPFLite provides macro functions GET_CSR_LPTR and GET_CSR_COL which, respectively, obtain the "rowPtr" and "column number" position of the cursor. But as far as I can see, there is no way to precisely position the cursor, except via SET_CSR(row,col), but that only takes effect when the macro ends.
The situation I have is as follows.
A macros starts and I save the cursor position (rowptr,column) it inherited from the user. This starting position is important for the processing that the macro does, bui before I can start this processing, I need to determine some other information. This determinaton involves some FIND commands, which, by definition, move the cursor. Once the information is known, I need to reposition the cursor to where we started, but the best I can do is use a "LOCATE !rowptr" to place the cursor on the line number field of the row where it was. I have no way to position the cursor at the correct, or indeed any, column in that row. SET_CSR is pointless because it does noting until the macro ends, and it isn't about to end.
What obvious clue am I missing, apart from a new function to allow a macro to to place the cursor at a given column in a data row?
|
|
|
|
Post by George on Oct 23, 2022 10:40:31 GMT -5
Stefan: This is getting into some very tricky areas, especially if you are resetting the cursor in preparation for some FIND type commands. The main search routine has to set the starting line/col position based on a large number of factors. - Is this a FIND or RFIND?
- Was the last search successful or not?
- What direction was the previous search? Is this a 'rollover' from Top to Bottom or visa versa.
- Where is the physical cursor on the screen? Is it even within the text area?
- Where did the last Search set the resume position?
- Is it an ALL request?
- Any specific NEXT, PREV, FIRST, LAST?
- Is it using variable length search strings (REGEX or Delimited literals)?
So I can easily create a new function to set the internal line and column, but depending on the conditions above, it may not end up being honored.
George
|
|
|
|
Post by Stefan on Oct 23, 2022 16:01:47 GMT -5
So the question becomes... Could a new macro function set the cursor position in such a way that, the main search procedure obtains the correct 'base' information which it then 'adjusts' according to the purpose for which it was invoked? The physical/visible cursor need not necessarily appear at that position because the user doesn't get to see it again until the macro finishes.
Actually, in this particular case (needed to know where the cursor was at the start of the macro), I wonder if TRACK might help. I'll have a look at that when I have time, but I think Track only also only gives me the line, not the column.
|
|
|
|
Post by George on Oct 24, 2022 10:03:49 GMT -5
Get_Trk_Pos$ returns TOS, line and column numbers.
|
|
|
|
Post by Stefan on Oct 24, 2022 11:21:53 GMT -5
Thank you, George, I realised the same when I tried it, but it didn't help. The call doesn't move the cursor to that place (not really surprising, I was grasping a straw that didn't hold my weight :-)) The problem to be solved was how to put the cursor at a particular column, not determining which column it needs to be - I already had that info.
I usually get a little kick out of taking an 'innovative' route to resolve an issue, but this time it didn't work out.
Back to the drawing board.
|
|
|
|
Post by George on Oct 24, 2022 12:55:18 GMT -5
Stefan: I tried a test version of a new function - Set_LCsr(line, col) (set Logical Cursor) to set the logical line/col position.
It seems to do what I think you want, you'll have to confirm it. If it doesn't then I'll yank it. I guess it will depend on how 'tricky' your macro is after the SET as to whether it will work for you. If it seems fine, I'll leave it in and document it with a caveat that it MAY not do what's wanted.
George
|
|
|
|
Post by Stefan on Oct 25, 2022 6:47:33 GMT -5
Thanks George, I'll look forward to that. The most frequent use for Set_LCsr(line, col) will come from situations where I need to use one (or more) location-changing command(s) to determine something and then return to the starting point to perform the actual work. In the majority of cases, this isn't an issue because (a) Often knowing the "return-to" line is sufficient, albeit with a bit tinkering.
(b) I can 'collect' any important data at the row/col position BEFORE I wander off to decide what to do. (c) I reached the 'origin' via a command like FIND, so I can just re-issue the FIND command, this time limited with a line range of !<original-line-pointer>, to get back there. (Works fine unless the search string appears multiple times on that line, but I'd probably know that.)
It is just odd that one cannot ensure that the next SPF_CMD will 'commence' at a specific row/col position. There's a kind of 'disconnect' between commands issued from a macro and those issued manually by the user. The user can and frequently does commence a search in a completely different place to where the previous command finished, just by moving the cursor. Hence, regardless of whatever any prior command(s) did, a manual command like FIND 'ABC' must ALWAYS obtain the then cursor position before commencing its search.
But a macro, cannot move the cursor and thus cannot mimic/automate the user's behaviour.
In my simple(!) mind, that probably means that part of the 'ATTN event' (e.g. ENTER key) saves the cursor location someplace for any subsequent command to find. Given there isn't an 'ATTN event' between one macro SPF_CMD stmt and another, I'm guessing that Set_LCsr(line, col) records the macro position in the 'usual' location instead.
If this is even close to being correct, and assuming it works as expected, Set_LCSR(...) should probably also update the values for .ZCSR, etc, to avoid mishaps.
PS: I also wonder if the existing SET_CSR(...) function would be less confusing, if it were called Post_Set_Csr(....).
|
|
|
|
Post by Stefan on Dec 2, 2022 7:03:35 GMT -5
George, Thanks for GET_LCSR(), but I don't think it works, so you can yank it out again. I've had another idea, based on the FIND comand. e.g. Lptr = Get_CSR_LPtr ' save cursor position
col = Get_CSR_Col
' code here that wanders off to do whatever
SPF_CMD("FIND DX p'=' !"+Lptr+" "+col+" "+col) ' return cursor to where it was It has a few bits wrapped around it to allow for Line pointers changing, but basically it " finds any character, searching only in the original line and the original column".
Works a treat.
|
|
|
|
Post by Stefan on Dec 2, 2022 13:48:58 GMT -5
Robert,
Good thinking, but if the line has zero length, it is very unlikely that it held a cursor in the first place. Perhaps in col 1, but I could cater for that.
And for my needs, the situation won't arise. Every one of my profiles has a nonzero MINLEN specified, usually around 100.
|
|
