Serious error of RegExp and VBScript.RegExp in Office 365 version affects stdRegex

[SanbiVN]

Hi @sancarn When I call two new regular expression library test routines RegExp in Excel 365 it causes the application to crash If I initialize and run with VBScript.RegExp library, I get an error message like below

' Run -> message box error and crash Excel 
Sub VBA_365_RegExp_test()
  ' RegExp in Office 365
  With New RegExp
    .Global = True
    .IgnoreCase = True
    .MultiLine = True
    .pattern = "(.)(?=.*\1)"
    Debug.Print .test("ss")
  End With
End Sub
' Run - message box error 
Sub VBA_VBScript_Regex_test()
  With Interaction.CreateObject("VBScript.RegExp")
    .Global = True
    .IgnoreCase = True
    .MultiLine = True
    .pattern = "(.)(?=.*\1)"
    Debug.Print .test("ss")
  End With
End Sub

Can you test on your Excel VBA to see if this error occurs, I have been getting this error recently, since Office was updated, and the RegExp library was embedded directly into VBA.

Hopefully this bug will be fixed soon in the future.

[DecimalTurn]

Related: https://stackoverflow.com/questions/79759372/vba-vbscript-regular-expressions-crashes

[DecimalTurn]

Also this: https://github.com/GCuser99/SeleniumVBA/discussions/166

[SanbiVN]

Hi @DecimalTurn Because of that error, I tried to utilize Pcre2 into VBA, Pcre2 is better than RegExp, but need to load library. Using Pcre2, the performance is really good, and I avoid a bug that exists in RegExp, which is when using multiple .*, .*?, .+? syntax in the expression, causing endless process occupation.

[sancarn]

Yeah I need to fully migrate over to the new stdRegex created by @sihlfall. This should fix this issue.

See: https://github.com/sihlfall/vba-regex/blob/master/stdvba_regex3/stdRegex3.cls

[SanbiVN]

I tested @sihlfall's project, although it is a good solution but the performance is not good. Because VBA is not a good environment for Regular Expressions. I wish he could develop the project in TwinBasic taking advantage of multithreading.

[sancarn]

@SanbiVN Indeed, ofc a DLL will always execute faster than interpreted pcode 🤷 Just the way it is, not going to be something we use for stdVBA though unless. Only way I would be comfortable with it is if the VM itself was in inline-assembly.