Invoke Intelliprompt like in Visual Studio

SyntaxEditor .NET Languages Add-on for Windows Forms Forum

Posted 15 years ago by Alex
Version: 4.0.0280
Avatar
Currently in .NET add-on the Intelliprompt is invoked by pressing “.”, so in order to see a list of object properties we need to type “this.”. How can I implement the VS behavior where the list is displayed automatically when we just start typing?

Thanks
Alex

Comments (7)

Posted 15 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Alex,

The best way to do this would be to look for A-Z key presses. If you see one, check to see if that letter forms a single word maybe by using something like editor.Document.GetWordTextRange for the previous offset and see if the range is length 1. Then if those conditions are met, call your language's ShowIntelliPromptMemberList method. That's what we would do at least.


Actipro Software Support

Posted 14 years ago by Tim
Avatar
Hi, any updates to the .Net add-in to simplify this? (doesn't happen in your sample)

You only want it to happen if you are specifing a type, and not an identifer.

e.g.

int a = 3;

I only want the Intelliprompt to display when I enter 'i', and not on a (or anywhere else).

Is there a simple way of getting AST info that would identify which part of statement I'm at if there is no built in support for this?

Cheers,
Tim
Posted 14 years ago by Tim
Avatar
And continuing along this theme of replicating VS..

Simplest way of knowing what class to preselect in Member list for 'new' statements? I guess I need to access AST to figure this out.

Tim
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Tim,

The IAstNode.FindNodeRecursive method lets you recurse down an AST and find the lowest node that contains an offset. That should help you. You can get the AST from the document's SemanticParseData property.

However you have to also consider that generally while typing a new statement, it may not fully be valid and thus the AST may not have "good" data for around the caret. Also the parsing is done in a worker thread so there is a brief delay between when a character is typed and when the document's SemanticParseData is updated. Thus a lot of times we do a combination of token scanning and AST examination when trying to determine the code that has been entered.


Actipro Software Support

Posted 14 years ago by Tim
Avatar
Thanks, I did have a play yesterday with scanning surrounding tokens and figured out that I would likely have to wrap that up into a routine.

For the following statement:

List<string> s...

I would get an IToken back with a Keyword of 'String' for the 'string' part, it seems everything is autocapitalised? (Does the same for non identifiers in declarations e.g. Return, Public etc.

To interpret the Token.Key value, I guess I need to have a list of reserved words such as Identifier, LessThan, DecimalIntegerLiteral, StringLiteral etc, anything else is an actual type?

Cheers for good responses.
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Our add-on works pretty much by ID values and translates them to strings mostly for debugging purposes since it's easier to see what a token is by looking at "String" vs an ID number like 47, etc.

Check out our CSharpTokenID class as it has static props for each token ID used by the add-on. So you can switch on the token.ID and do case statments that look for things like CSharpTokenID.StringLiteral, etc. CSharpTokenID has prop entries for each keyword/operator, etc. and one for a general Identifier.


Actipro Software Support

Posted 14 years ago by Tim
Avatar
Excellent, thanks, that's enough to move forward.
The latest build of this product (v24.1.0) was released 3 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.