|
|
Post by Stefan on Jun 24, 2021 3:13:15 GMT -5
Hi Guys,
I've been playing around with regular expressions in macros, which has led me to this observation.
When the 'search argument' specifies a 'pattern' to be found, rather than a simple 'string', there's no easy way to determine what was actually found. For example: To find "characters ABC, optionally followed by any number of other alphanumerics, followed by a colon and a blank" you can use FIND R'(ABC[a-z0-9]+)(:\h)' In this case, two new functions GET_FOUND_STR$ and GET_FOUND_LEN would be helpful. GET_FOUND_STR$ would returnthe actual string that matched the 'search argument', e.g. for "ABC123:<blank>" and GET_FOUND_LEN would return the value 8.
I note that the FIND command does highlight the entire matching string (from ABC to <colon><blank>) on the screen, so the length (at least) of the 'occurrence' is known.
Robert Really sorry to hear you are feeling poorly. Always hard to shrug these things off at our age. Best wishes and get well soon!
|
|
|
|
Post by Stefan on Jun 24, 2021 10:37:45 GMT -5
George... Forget this request.
Perusing the ThinASIC document I realised I can access the actual string found with a simple found_Str$ = Parse$(Get_Msg$, "'", 2), immediately following the FIND command.
|
|
|
|
Post by George on Jun 24, 2021 14:20:34 GMT -5
Stefan: Get_Find_Col and Get_Find_Len to pull the data from the line with a MID$ would be safer. If the string was very long I would be concerned about the Msg string being truncated (or something) since it has a length limit.
George
|
|
|
|
Post by Stefan on Jun 27, 2021 14:45:29 GMT -5
George,
I was relying on Get_Find_Len and Get_Find_Col, but noted that the with a regular expression, Get_Find_Len always returns the length of the "search string" (i.e. the regular expression') and not the length of the actual data found. In the example, (ABC[a-z0-9]+)(:\h), the'+' allows a variable number of alpha-numeric chars to follow the specified ABC, up to the next <colon><blank> sequence.
So reading the line and 'grabbing' the text with MID$ isn't easy as the length is incorrect.
But I take your point about the Get_Msg$ text being limited in size.
Perhaps a GET_FOUND_STR$ (or GET_FIND_RESULT$) and optionally a GET_FOUND_LEN (or GET_FIND_RESULT_LEN) function would be useful after all.
I say 'optionally' as the length could be easily established using BASIC once I have the result string.
|
|
|
|
Post by George on Jun 27, 2021 15:09:21 GMT -5
Stefan: I'll check out Get_Find_Len. It should be returning the actual found length, seems like a bug. Yes, it was missed in the 2.5 upgrades, my apologies. Corrected in next release. George Or try the correction version SPFLite25.exe (544 KB) |
|
|
|
Post by Stefan on Jul 1, 2021 14:38:54 GMT -5
Hi George,
Thanks, the value of GET_FIND_LEN is perfect in version 2.5.21178.
|
|
|
|
Post by George on Jul 1, 2021 15:55:30 GMT -5
Stefan: Good, it will be in the next full release.
George
|
|
