Regex escape directly in RxPath?

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
mrt
Posts: 237
Joined: Mon Mar 16, 2020 11:31 am

Regex escape directly in RxPath?

Post by mrt » Thu Dec 15, 2022 8:52 am

Dear all,

is it possible to escape regex directly in Rxpath without the need of UserCode?

Scenario:
I get a value from a data source, which contains spaces and special characters like '(' or '/'.
This value needs to be selected in a dropdown control, but the dropdown item text is not equal to the value, but has leading and trailing spaces, so I cannot use

Code: Select all

@innertext=$myValue
but instead need to use

Code: Select all

@innertext~$myValue
Now because of the '~' the special characters are treated as RegEx control characters, so I need to escape them.

Example value 1:

Code: Select all

'ABC/DEF'
after escaping results to

Code: Select all

'ABC\/DEF'
which works fine.

Example value 2:

Code: Select all

'ABC DEF'
results to

Code: Select all

'ABC\ DEF'
which fails on Validation AttributeEqual as well as on AttributeContains.
Validating on AttributeContains is anyway too fuzzy, because there could be values like 'ABC DEF GHJ' which would result in a false positive.

I could escape the value, save in an additional variable just for the dropdown and use the original unescaped for validation, but this ends up in 2 variables for the same input field which seems messy to me.

If there was a possibility to directly escape in RxPath I could stick to only one variable and would have a clean solution then.

Any ideas?

Something similar was mentioned 9 years ago as request:
https://www.ranorex.info/request-xpath- ... 5050.html
but i do not know if this was implemented.

IvanF
Posts: 81
Joined: Thu Aug 11, 2022 8:55 pm

Re: Regex escape directly in RxPath?

Post by IvanF » Fri Dec 16, 2022 4:26 pm

Hi, you could try "starts with" instead of "contains" if the leading spaces behavior is predictable

[@innertext>$RegEx+$myValue]

where $RegEx = \s* (or a version of "any number of spaces").

The direct concatenation of '\s*' + $myValue doesn't seem to work, which may indicate a parsing issue on the Studio side. So, if the double variable approach also doesn't work for you, it's worth submitting a ticket for both the parsing check and the feature request of easier escape functionality.