Advanced Syntax Highlighting Problem

SyntaxEditor for Windows Forms Forum

Posted 17 years ago by Adam Dickinson
Version: 4.0.0238
In our language, we wish to colorize keywords that represent global variable names, function names, enum type names, etc. To do this requires the information provided by the results of the Semantic Parse. We've come up with two solutions, neither of which is 100% correct. I was hoping I could get some help with the problem.

Solution #1:
After the Semantic Parse has identified all of the keywords that can be colorized, we go back through the Document's Token collection and fixup the Tokens so they'll get highlighted correctly.

* This is not a thread-safe operation with the SemanticParsingService, but I found I could get it to work by "hacking" it with a try-catch.
* After altering the Tokens, the colors didn't change unless I somehow refreshed or invalidated the window. I could do this by alt-tabbing away and then back again, or highlighting the text.

The Fix:
If I could programmatically trigger a refresh, I'd be good to go. I tried calling Refresh and Invalidate on the Document but neither succeeded in what I wanted them to do. Stumped, it was at this point that I moved to Solution 2.

Solution #2:
I have a global keyword cache that is very similar to the DotNetProjectResolver, including how it saves the cache items to disk. Due to the way I'm using it, 9 times out 10 I already know all of the keywords before that first Lexical and Semantic Parse. So in the Lexical Parse when I identify keywords, I look into the cache to see how to colorize them.

* That 9 times out of 10 bit. If it is the very first time parsing the file, I don't have its keywords in the cache, so they won't be colorized until the 2nd time the file gets lexically parsed. After the first semantic parse, the keywords get saved to disk and will be preloaded the next time the file is loaded.
* In the Lexical Parser, I get keywords colorized that shouldn't be due to file dependencies. Say I have FileA loaded which defines "int myInteger". Then I load FileB, which includes FileA. Any instances of "myInteger" get colorized, as they should. But if I load up FileC, which does not include FileA, "myInteger" gets incorrectly colorized.

The Fix:
If I knew which Document was being parsed by the lexer when GetNextTokenLexicalParseData is called (in the case of a class derived from IMergableLexicalParser), I could figure out if a keyword was in scope and colorize it correctly.

Any help you could provide concerning either solution would be greatly appreciated.

Comments (2)

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA
Ok for solution #1, I looked through the code and believe in the short term you can trigger a repaint of all SyntaxEditor instances working on a Document by toggling the Document.ReadOnly on and back off. That will trigger a repaint for each toggle but other than that, it does nothing else (besides toggling a boolean).

But I've also added a Document.InvalidatePaint method for you which you can call. This will appear in the next maintenance release.

Actipro Software Support

Posted 17 years ago by Adam Dickinson
Oh, thank you so much for that. Toggling the ReadOnly status did the trick. Thanks!
The latest build of this product (v24.1.0) was released 4 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.