Announcement

Collapse
No announcement yet.

Minor Bug: Incorrectly marked as "Minor" Change

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Minor Bug: Incorrectly marked as "Minor" Change

    Txt1.cs
    Code:
    string X =
    @"
    ""
    ""//"">DEMO 1 ENDING";
    Txt2.cs
    Code:
    string X =
    @"
    ""
    ""//"">DEMO 2 ENDING";
    The last line of each C# code file is incorrectly marked as a minor difference rather than a major difference. This probably cannot be fixed without having the parser behave differently within C# from C and C++.

  • #2
    Hello,

    We can, if you'd like to create a new custom File Format for these files (or edit the C# one provided) in the Tools menu -> File Formats.

    The specific issue here is that:
    "" is detected as a string
    // is detected as the beginning of a comment
    then everything that follows is also a comment.

    If we define a grammar element that contains these elements and place it higher on the list, such as a new element:
    ""//"
    This would match on the beginning part of the line, allowing
    ">DEMO 1 ENDING"
    to match as a string.

    The key is that the new element will need to contain text that is in the same relative position as the other grammar elements, otherwise those leftmost elements will still be matched on first (even if they are lower in the priority list of Grammar Elements).
    Aaron P Scooter Software

    Comment


    • #3
      I don't think it's that simple. Consider this example

      Txt1.cs
      Code:
      string X =
      @"
      ""
      a//>DEMO 1 ENDING";
      Txt2.cs
      Code:
      string X =
      @"
      ""
      a//>DEMO 2 ENDING";
      Or maybe I am misunderstanding your point.

      Comment


      • #4
        Hello,

        Thanks for the example. I do see the issue you are running into. It has to do with the escape character not detecting in a delimited format that stretches over multiple lines and has the same character as the end of the delimit.

        In the meantime, to get the string to detect correctly, you'll need to have the escape character and end of string on the same line within BC3. Example
        Code:
        string X =
        @"
        ""a//>DEMO 1 ENDING";
        or
        Code:
        string X =
        @"""a//>DEMO 1 ENDING";
        Aaron P Scooter Software

        Comment


        • #5
          That sounds about right. Part of the problem may be that in C#, " is used *only* to escape " and nothing else. My temptation is to use
          Code:
          @"
          to
          Code:
          "("")*
          with a regex (i.e., start with @" and end when there is an odd number of double quotes). However, this doesn't actually work.

          Code:
          @"
          to
          Code:
          [^"]"("")*
          seems to work, but thinks these are different:

          Code:
          string X =
          @"
          ""
          ";//>DEMO 1 ENDING"
          and

          Code:
          string X =
          @"
          ""
          ";//>DEMO 1 ENDING"

          Actually, I think that may be a second issue...
          Last edited by Brian; 01-Oct-2012, 04:30 PM.

          Comment


          • #6
            Our RegEx does not support the full array of back referencing or lookbehind. That definition looks like it would match only when the quotes were on the same line, which our current delimited rule would match anyway?

            You can see a list of our supported RegEx commands using the dropdown button next to the textbox entry, or in our Help file. I can't think of one that would help work around this in this particular case. Have you had a change to try reformatting the text, and see that it does detect the grammar correctly if it is a single (or double) line with escape character and end character on the same line?
            Aaron P Scooter Software

            Comment


            • #7
              Originally posted by Aaron View Post
              Our RegEx does not support the full array of back referencing or lookbehind. That definition looks like it would match only when the quotes were on the same line, which our current delimited rule would match anyway?

              You can see a list of our supported RegEx commands using the dropdown button next to the textbox entry, or in our Help file. I can't think of one that would help work around this in this particular case. Have you had a change to try reformatting the text, and see that it does detect the grammar correctly if it is a single (or double) line with escape character and end character on the same line?
              Reformatting the text interferes with running a useful reasonable comparison. In this specific case, I was dealing with a large string separated out into multiple lines.

              Comment


              • #8
                You'll need to mark Comments (or other grammar types) that might occur in these strings as Important, as the multiline @" to " string might not catch them otherwise. You can set this default on the Home screen, in the Saved Sessions list, Edit session defaults folder, select Text Compare, and in the Importance tab check any unchecked items.
                Aaron P Scooter Software

                Comment

                Working...
                X