|
|
Post by Stefan on Jan 17, 2023 9:49:53 GMT -5
My LP.MACRO issues a FIND command like...
SPF_Cmd("FIND R`"+what$+"` NEXT DX")
The 'what$' RegEx is searching for the NEXT 'Function/Sub/Method/Class/Callback/etc' statement and I do not wish to change the Xstatus of the found line. Under normal circumstance, the above statement works fine. But if HIDE ON is in effect, the FIND command terminates with RC=8: HIDE mode and DX/MX require ALL keyword as well
This isn't an issue going forward as I've replaced NEXT with ALL to comply with the requirement and added a line range to return the correct result, e.g. SPF_Cmd("FIND R`"+what$+"` !"+fromherePtr+" .ZL ALL DX")
Question: I'm just curious, What is the reason for that requirement?
|
|
|
|
Post by George on Jan 17, 2023 12:51:44 GMT -5
Stefan: Very old and obscure restriction. There is some tricky logic in the handling of found locations, setting up for an RFIND and setting the cursor onto the ----- Exclude --- line itself. If the find location is on a hidden line, trying to set the cursor there, and the secret fields that hold that location just becomes ridiculous.
Just thinking about those requirements is enough to give you a headache.
George
|
|
|
|
Post by Robert on Jan 17, 2023 13:03:56 GMT -5
This was exhaustively thought out when the feature was added. HIDE mode and DX/MX prevents a FIND from showing a progression of find locations. If HIDE was off, the cursor could show progressive FIND's on one line by showing a cursor move, bit by bit, until the --- x --- line was passed. With HIDE on, that's not possible, and there would be utterly no user feedback. People would be scratching their heads and going, what the heck just happened here. It would be impossible to explain or document.
Bottom line: The user interface/user experience would be too difficult. It would be asking too much of people.
George wouldn't be the only one getting a headache; everyone would.
So why is it OK when ALL is included? Because ALL causes every search string to be found or changed without requiring a progression of find locations to be incrementally shown. It just does all of them, all at once, and then it's done. That makes showing the 'difficult' HIDE progression unnecessary.
That's why.
|
|
|
|
Post by Stefan on Jan 17, 2023 14:20:11 GMT -5
Thanks Guys. I understand. User issues a FIND command but the MX/DX prevent SPFLite from making the line visible. So what did I just FIND and where's my cursor now?  ? Makes sense when considering user interaction. It's not an issue within a macro as the user doesn't see the outcome and it was easy to get the desired result using ALL with a limiting line range instead. |
|
|
|
Post by Robert on Jan 17, 2023 15:45:47 GMT -5
What did you find? Maybe nothing. Never tried that before. Run a macro and grab the find-string result and display it. I am guessing that the error actually caused the find to fail, and you didn't find anything.
If you need to run this macro, my advice would be to detect HIDE mode, then temporarily disable it, then turn it back on when you're done.
|
|
|
|
Post by Stefan on Jan 17, 2023 18:33:37 GMT -5
No Robert, the code now works perfectly. It now finds exactly the same thing irrespective of whether HIDE is ON or OFF or whether the lines are visible or excluded.
Basically, having found the SUB/FUNCTION/METHOD/whatever the user asked for, the routine searches for the start of the following SUB/FUNCTION/...
It either finds one or reaches Bottom of Data if there are no more.
It then either SHOWS or EXCLUDEs the lines that make up the body of the function it initially found according to which 'view' the user requested.
There's no need to complicate things by messing around with HIDE mode.
Although the combination of DX with NEXT is not allowed, the error message specifically states that "...DX requires ALL..." so that combo is fine.
It just needed a line range to confine the search from 'here' to .ZLAST so 'ALL' doesn't start searching from Top Of Data. Simple.
|
|
? Makes sense when considering user interaction.