User Defined Error Parsing No Longer Works

[mrmorriskr]

I have "user" defined Error Parsing expressions that have worked for many versions of SlickEdit and pass the Validation test. The expressions correctly locate build error messages containing the filename, line, and column. Note that the error "message" is located on a different build error line and not of concern. For example:

2017-Sep-27 10:19:51.601
Parser:: ----- Warning in file D:\REFHSM_PAS\Config\Directors\Mill\TEST_JOB\datainit.cfg, line 4, col 46 -----
2017-Sep-27 10:19:51.601 4: DICTIONARY RECORD r_FceStat = t_r_FceStat;
2017-Sep-27 10:19:51.601 ^
2017-Sep-27 10:19:51.601 Parser:Warning: the equal operator "=" in this context has been deprecated, use " AS " instead

My problem is double-clicking on the error message no longer opens the filename referenced in the build window but instead opens the Find File dialog. The Find File dialog does not allow me to point to the file with a build error and does not display any files in the current directory. The Find File is pointing to the correct directory. I noticed that the path in the dropdown list is incomplete, but the tree list is opened to the correct build directory. For example, the Find File dialog contains the following in the drop-down list:
"M_PAS\Config\Directors\Mill\TEST_JOB\" for the above error message.

I have discovered that running Error Parsing Configuration Validate Expression Test before building causes SlickEdit to open the right file after double-clicking on the build error but still does not go to the error line and column but instead goes to the first line and column. SlickEdit no longer highlighting any of the build errors in the editing window.

Example expressions:
^Parser\:\:\c:b\*\*\*\*\*:b:bError in file:b{#0:p},:bline:b{#1:i},:bcol:b{#2:i}

^Parser\:\:Alarm\:\c:b\*\*\*\*\*:b:bWarning in file:b{#0:p},:bline:b{#1:i},:bcol:b{#2:i}

^Parser\:\:\c:b\-\-\-\-\-:b:bWarning in file:b{#0:p},:bline:b{#1:i},:bcol:b{#2:i}

This problem started with the version 21 and now in 22. Using all defaults and just adding the parsing error expressions reprocduces what I see.
Thanks,
Kevin

[Clark]

It looks like there is a bug with using "\c" in the error parsing. We will look into this further. For now, remove "\c" from all of your error parsing regular expressions. Also, one of your regular expressions has ":b:b" which won't work for the sample warning because there is only one space and not two. Try the following:

^Parser\:\::b\-\-\-\-\-:bWarning in file:b{#0:p},:bline:b{#1:i},:bcol:b{#2:i}

[mrmorriskr]

Normal behaviour restored!

Not sure why the "\c" was in the expression.  "\c" is used to define a control character and does not make sense here.  The misbehaviour could be that because the next character after the "\c" was not between A and z causing the parser to ignore the expression and move on to the next character.
Thank you,
Kevin

[Clark]

Actually "\c" in a SlickEdit syntax regular expression specifies where the "cursor" (or return index for the pos() function) should be. For some reason, this breaks the pos() functions ability to return match groups. It is definitely a bug with the pos() function.