>Hi Gregory,
>
>Thanks for jumping in:)
>
>A couple of questions, should you have already used them - and, even better, deployed them on a relatively wide scale.
>
>I have not tested regex(es) from VFP. Sure that could help. But I try to avoid bringing extra system-levels depencies as much as I can. I understand that CreateObject("VBScript.RegExp") would bring access the MS-W scripting engine. Which mean a dependency on an additional MS-W* functionality.
>
>Does that mean risk on the long run or can I really trust the service on the long run? I have some issues with the idea of using them as an external resources except if the integration can be fully and neatly performed i.e.the regex engine is robustly embedded into the application.
>
>I currently embed all resources that are used into the package. On top of vfp runtime dlls, I a bunch of system levels dlls just to make sure that dependencies may not break the stuff in the longer run (xml parser, gdiplus and others...). Can I do the same with MS-regex service? Including on legacy XP install?
>
>Daniel

There is a Foundation class, with source code, that wraps the access to VBScript.RegExp, so most of the required work towards neutrality is already done. You can change the class or extend it to use any other engine that may be available, in addition or as a replacement of VBScript.RegExp, but your code does not have to worry about it (probably).

As regular expressions are not used by VFP, there is no dependency at all: if you want to use them, you must instantiate an object from an external component. It's not like XML operations, that depend on the availability of a particular parser. But if you need to inject more power, say, because you need XPath 2.0 or something like that, then you must negotiate your objects outside VFP.