Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread EWB3 TRegExpResult.matches not being populated
Sat, Jan 23 2021 1:19 PMPermanent Link

R&D team @ Environment Canada

Hi Tim

I am trying to migrate my projects from EWB2 to EWB3 and have run into an issue with my regular expression code.
It appears that TRegExp.exec is not populating TRegExpResult.matches regardless of the parameters involved.

     strInput := 'SNUP';
     FstrRegexPattern:='(SN|RA)(UP)';
     FstrRegexOptions:='i';

     TempRegExp:=TRegExp.Create(FstrRegexPattern,FstrRegexOptions);
     Result:=TempRegExp.test(strInput);

     //Result is 'true'

     Result:=TempRegExp.exec(strInput);

     //Result.index = 0
     //Result.input = 'SNUP'
     //Result.length = 3
     //Result.matches = undefined

In EWB2 this code would run without issue, and I am unsure if I am missing something when converting to EWB3 or if this is a more fundamental issue.

Thanks for your time

Philip
Wed, Jan 27 2021 2:45 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Philip,

<< I am trying to migrate my projects from EWB2 to EWB3 and have run into an issue with my regular expression code.  It appears that TRegExp.exec is not populating TRegExpResult.matches regardless of the parameters involved. >>

Is this the exact code that you used with EWB 2 ?

The problem is caused by your use of the "matches" property, which doesn't actually exist as a property in the underlying RegExp class in JavaScript.  You should instead use the result like an array like this:

    TempRegExp:=TRegExp.Create(strRegexPattern,strRegexOptions);
    if TempRegExp.test(strInput) then
       begin
       TempResult:=TempRegExp.exec(strInput);
       ShowMessage(TempResult[0]);
       end;

EWB (both 2 and 3) define the property like this:

  external TRegExpResult emit RegExpResult = class
     public
        { Properties }
        property matches[index: Integer]: String read; default;
        property index: Integer read;
        property input: String read;
        property length: Integer read;
     end;

The key here is the "default" attribute, which makes the use of the matches property name unnecessary.  It also just so happens to allow EWB to define array properties for external JavaScript classes, and this also means that the "matches" property name is, ahem, fictitious.  The WebDOM unit has quite a few classes that have properties that work this way, so you should always check the original JavaScript to see how the properties are named in such cases.  This is also why EWB wraps much of the JS API in order to hide these types of details.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Feb 2 2021 4:13 PMPermanent Link

R&D team @ Environment Canada

Hi Tim,

Thank you so much for pointing out that I can use array notation to access the results. That has indeed fixed my problem. It is nice to know that all I have to do is remove '.matches' from my code.

Thanks for your hard work on EWB3.

Phil
R&D Team
Canadian Meteorological Aviation Centre
Edmonton, AB
Image