GoToPreviousMatchingToken for Dynamic Languages

Comments (8)

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Chris,

You are correct, it will not work for dynamic languages. That method uses the MatchingTokenID property of the token you pass to determine which token ID to look for. This is designed for advanced language implementations that create custom tokens. In those cases, you would override that method and do a switch on the current token's ID to determine what ID value to return as the matching token ID.

Actipro Software Support

Posted 17 years ago by Chris Morris

Thanks for the quick response. I suspected as much.

Sometimes the Actipro Documentation is unclear on which methods require advance language implementation.

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

I'll add a note about that in the GoToPreviousMatchingToken remarks. Also, there is an overload that lets you specify the end token ID. So if you assign token IDs in your dynamic language XML definition, then you can reference the appropriate one when using that second overload.

Actipro Software Support

Posted 17 years ago by Chris Morris

Thanks! Yes by specifying a TokenId in the dynamic language xml file and using the overloaded GoToPreviousMatchingToken with a Token StartID works!

Here's the working code example if anyone else is interested:

XML File:
<ExplicitPatternGroup Key="OpenParenthesisPatternGroup" TokenKey="OpenParenthesisToken" PatternValue="(" EndBracket="CloseParenthesisPatternGroup" TokenID="123"/>
<ExplicitPatternGroup Key="CloseParenthesisPatternGroup" TokenKey="CloseParenthesisToken" PatternValue=")" StartBracket="OpenParenthesisPatternGroup" TokenID="456"/>

Source Code:
TextStream stream = syntaxEditor.Document.GetTextStream(syntaxEditor.Caret.Offset);
IToken token = stream.ReadTokenReverse(); // ) token
bool found = stream.GoToPreviousMatchingToken(token,123);
token = stream.Token; // ( token !!

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

Then just to make your code more readable, you can use an enum or class with constants on it. And the root SyntaxLanguage tag has an attribute where you can specify that class.

Actipro Software Support

Posted 17 years ago by Matthew Smith - Developer, One Plus One Solutions Pty Limited

Quote:
Then just to make your code more readable, you can use an enum or class with constants on it. And the root SyntaxLanguage tag has an attribute where you can specify that class.

Could I clarify what you suggesting here.

Add this to the dynamic language definition:


<SyntaxLanguage Key="VB.NET" LanguageDefinitionVersion="4.0" Secure="True" 
    SyntaxLanguageTypeName="TestApplication.VBDotNetDynamicSyntaxLanguage, TestApplication"
    TokenIDTypeName="TestApplication.TokenID, TestApplication"
    xmlns="http://ActiproSoftware/SyntaxEditor/4.0/LanguageDefinition">

Create the TokenID class (along the lines of this):


Namespace TestApplication
    Public Class TokenID
        Public Const [InvalidToken] As Integer = 0
        Public Const [DocumentEndToken] As Integer = 1
        Public Const [WhitespaceToken] As Integer = 2
        Public Const [LineTerminatorToken] As Integer = 3
        Public Const [ReservedWordToken] As Integer = 5
        Public Const [VariableWordToken] As Integer = 7
        Public Const [MaxTokenIDToken] As Integer = 8
    End Class
End Namespace

The above token name matching the TokenKey fields as follows (example):


<!-- Whitespace -->
<RegexPatternGroup TokenKey="WhitespaceToken" PatternValue="{WhitespaceMacro}+" IsWhitespace="True" />
<!-- Line Terminators -->
<RegexPatternGroup TokenKey="LineTerminatorToken" PatternValue="{LineTerminatorMacro}" IsWhitespace="True" />

The main reason I wish to switch is to ensure my parenthesis brackets match (as above previous message) for Intellipromt, but also so I can use the TokenID field rather than the TokenKey string (? would this not be quicker??)

[Modified at 03/27/2007 01:28 AM]

Regards, Matt

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

Yes I believe that looks correct. Actually I don't think you need the "Token" on the end of each const name either. It will find the const either way and is less typing to write it without that.

Yes numeric comparisons are always going to run faster than string comparisons.

Actipro Software Support

Posted 17 years ago by Matthew Smith - Developer, One Plus One Solutions Pty Limited

Yeh, did notice the non-requirement for 'Token' on the end!

Thanks for the confirmation on the speed of using IDs instead of Keys - thought I'd read that previously.

Also I've started to get into the more advanced stuff recently, this control is great - was able to add intellisence in the space of a day or so! Awesome stuff!

Regards, Matt

The latest build of this product (v24.1.0) was released 2 months ago, which was after the last post in this thread.

Comments (8)

Add Comment