|
Post by George on May 7, 2021 10:30:28 GMT -5
I'll see what I can do.
George
[DONE]
===> What a guy, what a guy - R
|
|
|
Post by George on May 9, 2021 9:02:42 GMT -5
Robert: Exactly the type of thing I expected to occur. I'm sure it's another place where the variable used had to change and it was missed.
George
|
|
|
Post by George on May 9, 2021 14:24:09 GMT -5
Robert: Did some further cleanup on the parsing routines, even though I eliminated a lot of the duplication, there was still a problem with multiple fields containing multiple variations of the operands. So I took the machete and did even more pruning and simplification. It's at the minimum now, so after some more testing I'll post another version to try.
George
|
|
|
Post by George on May 10, 2021 13:39:21 GMT -5
Robert: DEL had an incorrect Parse flag, so it 'swallowed' the 2 2 operands as a line number range. When you stare at stuff like this too long it's no wonder silly errors creep in.
IF me.ParseCriteria("ASDMC1PUR") THEN MExitMeth ' Scan (All, Subset, Direct, Modifier, Cols, Lit1, Clr, User, Range)
I had the last 'R' as a '#', which means line ranges can also be coded as simple numbers.
Good spot. Corrected for the next round.
George
|
|
|
Post by George on May 11, 2021 8:50:31 GMT -5
Robert: Well MUEH's suggestion was right on the money. Thinking about it, it was one of those head-slapping "why didn't I think of that" moments. It made recreating the pop-up message trivial, as well as checking that the fix DID prevent it from happening.
Yes, the internal changes were extensive, much more than I had anticipated. But once started it became an "if I'm doing this, I might as well do it all", so it kind of grew. There used to be 3 phases to parsing command lines.
A) broke down the words, and identified the type of each operand (KWD, string, numeric, tag, etc.)
B) was optional, and extracted line range operands and removed them from the parsed word-list.
C) determined if the operand was 'allowable', extracted the real data (removed quotes, converted Hex, handled split positions etc.) and built the data block that the universal search/change routine uses.
The B) step is now embedded in C). And the search data block is now an Object rather than just a collection of similarly named variables.
None of the actual logic of the various Primary commands was altered, just some tweaking of their parsing calls and the names of the search/change variables they use.
So 2.5 is an internals release, very little in the way of change for the users.
Safe? Well, I'm using it regularly, including for the SPFLite source itself in MEdit mode. Had to tweak my PB.MACRO to handle MEdit sessions so that it pointed at the correct line when a compile error occurred.
So I'm treating it as safe, but with a watchful eye.
George
|
|