Regex is not declared

Help
1

When using Regex I get an error message saying that Regex is not declared. How can I resolve this?

Thanks

4 Likes
2

I found how to resolve the error by adding the full library path system.Text.RegularExpressions.Regex.IsMatch like:

system.Text.RegularExpressions.Regex.IsMatch(DateTaskAttrib, “(JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC)-\d{2}”)

Hope helps someone else

9 Likes
3

Hi @selrac,

You may also use the Matches activity which is used for Regex operations.

1 Like
4

Hey @selrac

If you will get such thing then then namespace is not defined for that , So you can import that namespace in the below bar and can use onward in your project but as per my view better to use always to call full namespace so you will not need to import it and you will not get such error as well.

Capture.PNG948Ă—289 9.45 KB

and for your knowledge you can also use this predefined activities as well as @acaciomelo mentioned.

Regards…!!
Aksh

12 Likes
5

I beg to differ - always fully qualifying makes code a lot harder to write and read. There’s very little benefit to not importing a namespace (unless you’re microoptimizing memory usage).

6

You are already a unique champion :wink: pal @andrzej.kniola

Agree but Namespace imports are simply time savers / readability enhancements for the source code, the resulting code is exactly the same as if you had typed out things like System.Collections.Generic.List (for example).
Namespace imports are a compile-time feature and the generated IL will be exactly the same either way.There’s no performance difference.

Actually good to import always but what i have faced when running my workflow on different UiPath installed systems and in my system i have imported many other required namespaces so do not know the actual reason behind it although my workflow should not show any error with some imported functions but it was showing so then i have noticed so to make sure now i am following this approach and observed and read also they both takes the same approach :slight_smile:

So Depends on the programmer who is coding haha

Regards…!!
Aksh

1 Like
7

Normally yes, but in UiPath, since the code is interpreted from xaml (text form)… Not so sure about it. Since we don’t know how exactly everything works under the hood, importing is the safest way to make sure that everything is where it should be (also will show naming conflicts).
Especially for Rookies section, where these things might be read by people who don’t know all the implied things that do happen if you fully qualify vs. import. And in UiPath there’s even a little extra to it (not confirmed, but there’s something more happening under the hood IMHO).

Namespace management is a little bit more difficult than in other IDE’s (f.e. most show unused using statements), but that doesn’t mean we should throw it out the window :wink:

Tell me that when you go back to your code after 1 year or someone else will need to debug it ;). Readability is the key to maintainability.

Maybe, maybe not :slight_smile: . From practical, generic perspective though, I’d say import > fully qualify.
But whatever works for your team, I guess :slight_smile:

Cheers,
A.

2 Likes
8

haha comment will be there lol :slight_smile:
Thanks in UiPath will import always :smiley: :stuck_out_tongue:

Regards…!!

2 Likes
9

Thanks Aksh. I didn’t know about the namespace :open_mouth:. I’ll go for that.