Rubberduck: Parse error for clean code has returned version 2.1.1.2433

[ghost]

With the above version of Rubberduck I'm once again seeing Parse errors (Previous post was #2990).

RubberduckLog.txt

[MDoerner]

I just had a look at the log and it does not seem to be coming from version 2.1.1.2433 mentioned in the title.

Are you sure that logging is enabled? It might have gotten disabled when switching to the new version. If it is disabled, the old log does not get cleared.

[ghost]

So the first line of the log file being

2017-10-27 19:38:51.6171;TRACE-2.1.1.2433;Rubberduck.Common.LogLevelHelper;

Doesn't reflect reality???

Looking at the log file this morning shows it has changed with the first line being
2017-10-28 07:54:26.9227;TRACE-2.1.1.2433;Rubberduck.Common.LogLevelHelper;

[MDoerner]

Many apologies. Something must have gone wrong on my side when downloading the log file last night. Again, many apologies. The caching issue seems to be on my side.

Now, I had a look at the log file you uploaded. Unfortunately, I cannot identify the issue from what has been logged. Would it be possible for you to provide the code that is at the place where the error is reported. (Please note that currently the reported position refers to the exported module/class. So the position will be offset by a few lines relative to the position in the code pane.)

[Vogel612]

2017-10-27 19:39:03.2529;WARN-2.1.1.2433;Rubberduck.Parsing.VBA.ComponentParseTask;Syntax error; offending token ')' at line 56, column 56 in module Project.frmHeadingNumbering.;
2017-10-27 19:39:03.2639;ERROR-2.1.1.2433;Rubberduck.Parsing.VBA.ComponentParseTask;Exception thrown in thread 9, ParseTaskID b957e16d-7135-44c8-be45-e9f902e2ea14.;Rubberduck.Parsing.Symbols.SyntaxErrorException: extraneous input ')' expecting {',', '!', '.', '&', AND, EQV, IMP, IS, LIKE, MOD, OR, XOR, '/', '\', '=', GEQ, '>', LEQ, '(', '<', '-', '*', NEQ, '+', '^', WS, LINE_CONTINUATION}
   at Rubberduck.Parsing.Symbols.ExceptionErrorListener.SyntaxError(IRecognizer recognizer, IToken offendingSymbol, Int32 line, Int32 charPositionInLine, String msg, RecognitionException e) in C:\projects\rubberduck\Rubberduck.Parsing\Symbols\ExceptionErrorListener.cs:line 10
   at Antlr4.Runtime.ProxyErrorListener`1.SyntaxError(IRecognizer recognizer, Symbol offendingSymbol, Int32 line, Int32 charPositionInLine, String msg, RecognitionException e)
   at Antlr4.Runtime.Parser.NotifyErrorListeners(IToken offendingToken, String msg, RecognitionException e)
   at Antlr4.Runtime.DefaultErrorStrategy.Sync(Parser recognizer)
   at Rubberduck.Parsing.Grammar.VBAParser.lExpression(Int32 _p) in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 17938
   at Rubberduck.Parsing.Grammar.VBAParser.expression(Int32 _p) in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 16810
   at Rubberduck.Parsing.Grammar.VBAParser.expression(Int32 _p) in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 16889
   at Rubberduck.Parsing.Grammar.VBAParser.tuple() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 13694
   at Rubberduck.Parsing.Grammar.VBAParser.lineSpecialForm() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 13308
   at Rubberduck.Parsing.Grammar.VBAParser.mainBlockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 2005
   at Rubberduck.Parsing.Grammar.VBAParser.blockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 1633
   at Rubberduck.Parsing.Grammar.VBAParser.block() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 1549
   at Rubberduck.Parsing.Grammar.VBAParser.subStmt() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 11797
   at Rubberduck.Parsing.Grammar.VBAParser.moduleBodyElement() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 1484
   at Rubberduck.Parsing.Grammar.VBAParser.moduleBody() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 1389
   at Rubberduck.Parsing.Grammar.VBAParser.module() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 365
   at Rubberduck.Parsing.Grammar.VBAParser.startRule() in C:\projects\rubberduck\Rubberduck.Parsing\Grammar\VBAParser.cs:line 268
   at Rubberduck.Parsing.VBA.VBAModuleParser.Parse(String moduleName, CommonTokenStream moduleTokens, IParseTreeListener[] listeners, BaseErrorListener errorListener, ITokenStream& outStream) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\VBAModuleParser.cs:line 31
   at Rubberduck.Parsing.VBA.AttributeParser.Parse(IVBComponent component, CancellationToken token, ITokenStream& stream, IParseTree& tree) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\AttributeParser.cs:line 66
   at Rubberduck.Parsing.VBA.ComponentParseTask.RunAttributesPass(CancellationToken token, IParseTree& attributesTree, IDictionary`2& attributes) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ComponentParseTask.cs:line 136
   at Rubberduck.Parsing.VBA.ComponentParseTask.Start(CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ComponentParseTask.cs:line 54

[Vogel612]

What constitutes "Clean Code"? I assume you did compile the vba code... Can you show us the lines around line 56 of the module frmHeadingNumbering? Do note that the line is offset by about 8 lines, so the error should be on line 48 or something....

[ghost]

Sorry for causing confusion. My use of clean code means that it compiles without error (not clean code as per Uncle Bob - although having watched some of his youtube videos recently that's now what I'm working towards)

[ghost]

The code requested is attached
frmHeadingNumbering .txt

Obviously all of the stuff before the option explicit is normally hidden in VBA

Basically the code retrieves comma separated values that were previously stored in the document CustomXMLPart.

captures any changes made by the user

then saves the results back to customxmlparts for use elsewhere in the project.

doc_xml is an object which provides a simplified api for reading and writing to the document CustomXMLParts

[MDoerner]

Now I see what is going on here.

The exported module text, which we parse to determine module and member attributes, which only show up in there, does not conform to how the VBE displays the code.

More precisely, instead of Me.Left = Application.Left(0.5 * Application.width) - (Me.width / 2), the exported code in the module provided is Me.Left = Application.Left (0.5 * Application.width) - (Me.width / 2). Note the extra whitespece after Left; the VBE always suppresses such whitespace.

This confuses our parser. Changing the parser to be able to deal with this will be a challange.

[MDoerner]

@SteveLaycock Could you try whether the problem persists if you delete the content of the user form code behind, save, reinsert the content and save again?

Since there are no member attributes in this form, this should not lead to a loss of information in the code behind.

My hope is that removing and reinserting the code makes the VBE output the same code on export as can be seen in the code pane, apart from the attributes of course.

[ghost]

MDoerner,Thanks for the suggestion. I did as you requested and was amused to find that the repasted code would not compile.

The two lines

Me.Top = Application.Top  (0.5 * Application.Height) - (Me.Height / 2)
Me.Left = Application.Left  (0.5 * Application.width) - (Me.width / 2)

are incorrect as .Top and .Left do not take arguments.

Now the code I posted has been running nicely, displaying the user form and returning the correct results but it appears that the text has been corrupted as there is a missing + after the .Top and .Left.

The correct version of the code is

Me.Top = Application.Top + (0.5 * Application.Height) - (Me.Height / 2)
Me.Left = Application.Left + (0.5 * Application.width) - (Me.width / 2)

Unfortunately I'm still getting a parse error

RubberduckLog.txt

[MDoerner]

OK, with the + it makes more sense.

I just tested it live in Excel and I can reproduce the issue.

The problem seems to be our special export code for user forms, again: our export code removes the +. The VBE exports the correct code, apart from the extra line at the end. Moreover, if I insert the code into a class module, everything is fine.

One of the last PRs has changed something there to fix another issue.

[MDoerner]

I just looked it up: In UTF-7, the character + must be escaped. Otherwise, the charachter gets replaced by a space or ignored, depending on decoder.

So, the PR changing the encoding used in the special handling of the user forms caused this issue, indeed.

[ghost]

Thanks for taking the time to investigate this issue.