Bug with FIndNext and Normal search pattern provider

SyntaxEditor for WPF Forum

Posted 6 years ago by 7Alpha7
Version: 11.2.0552
Platform: .NET 4.0
Environment: Windows 8 (64-bit)
Avatar

Hello,

there is a bug with the FindNext (and also ReplaceNext) method :

 

public void testFindNext() {
            CodeDocument doc = new CodeDocument();
            EditorSearchOptions opt = new EditorSearchOptions { FindText = "A", MatchWholeWord = true, SearchUp = false, PatternProvider = SearchPatternProviders.Normal };
            doc.SetText("AA");
           ISearchResult  r =  doc.CurrentSnapshot.FindNext(opt, 2, true).Results.FirstOrDefault();
           bool haveBug = r != null;
           opt.MatchWholeWord = false; 
           r = doc.CurrentSnapshot.FindNext(opt, 2, true).Results.FirstOrDefault();
           haveBug = r != null; 
           doc.SetText("@A");
           opt.MatchWholeWord = true;
           r = doc.CurrentSnapshot.FindNext(opt, 2, true).Results.FirstOrDefault();
           haveBug = r != null;
        }

 

For the first search with the "AA" text and MatchWholeWorld = true the result is the one expected, i.e null.


For the second search with the "AA" text and MatchWholeWorld = false the result is not the one expected. There is a match though it should not.


For the third search with the "@A" text and MatchWholeWorld = true the result is not the one expected. There is a match though it should not.

So two kinds of problems : the one with MatchWholeWorld = false and the one with the @ (and possibly other as I can see, such as $ and [ and ..)

Regards.

[Modified 6 years ago]

Comments (2)

Answer - Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

For the second search, you are telling it it can wrap (your true parameter) so it finds the first A.  If you pass false there, it should return no results like you want.

For the third search, MatchWhole word makes the search pattern inject \b (zero-width word boundary check) into the search regex.  Since @ is not a word character and since you allow wrap (via true), it matches the A.  If you wish to have different behavior you can use a regular expression pattern instead and exactly specify your look-ahead/look-behind criteria.


Actipro Software Support

Posted 6 years ago by 7Alpha7
Avatar

Allright, I have misunderstood the use of the canWrap parameter. I didn't know it did what it does ! This way it's clear and results are the one expected.

Thank you.

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.