Re: [Clip] Re: Testing for Well Formed Numeric Field
- At 01-03-2013 23:03 +0000, Joy wrote:
>Hi Art.Actually, the "^" means start of selection, if any, start of line if not.
>I'm not nearly as good at RegExp at others but I'll give you what I have so far. I'm unclear about your data and what you mean by "the selection may be preceded or followed by any text" since your example started with ^\s[\+-] which means start at beginning of line...
What I was trying to convey was that at this point in my clip a selection exists, it contains at least one non-white-space character, is restricted to a single line and that the selection could be anywhere in a line - there could be text preceding and/or text following the selection. The "^" was necessary to ensure that the search pattern started from and included the start of the selection.
>This may help you start down the right path.Thank you for the suggestion. However, that pattern will only find valid numeric strings followed by white space to the EOL. My selections may be followed by any text, not just white space. And I need to ensure that within the selection, no non-digit character appears following the first digit. That is what the [\D] class was supposed to do. Oops! PAUSE. STOP. RETHINK.
Well now, between the two of our misconceptions, I think we've got it.
Writing the above explanation evoked a new line of thought. I had been trying to test if an invalid character existed in the selection ("\s*\d*?\K[\D]", a positive negative) and you were going by my stated goal of verifying a valid field ("\s*\d+", a positive positive). I took my approach as I didn't know of a way to ensure that the search didn't stop short of the entire selection. However, that is exactly what the "$" meta character means: End of selection, if any, EOL if not. I had thought the "$" only meant EOL. Your use of it made me look it up. Learned something new.
So a working search pattern becomes simply:
^!Find "^\s*[\+-]?\s*\d+?$" HRS
Thanks. You did help.
Now, I wonder if anyone picked up on the different behaviors of Toolbar "Find Text" between the F3 and mouse invocations.
- Seems to work I think ...
^ *(\+|-)? *?([\d\.]+)(?! )[^\d\r\n]*$
On 1/3/2013 6:03 PM, joy8388608 wrote:
> For example these would all be well formed, valid fields:
>> + 123
>> - 123
>> + 3
>> + 356456 [next line is at EOF]
>> + 3
>> And these would all be ill-formed, invalid fields:
>> -+ 123 [multiple operators]
>> 2+23 [embedded operator]
>> - 1 23 [embedded white space]
>> + aa 3 [non-digit character]
>> 2 [trailing white space] [next line is at EOF]
>> a+ 3