Customizing Intelliprompt in .NET AddOn - SyntaxEditor .NET Languages Add-on for Windows Forms Forum

Posted 15 years ago by Kevin Bennett

I am looking at different ways for filtering the member lists that popup in the SyntaxEditor Intelliprompt. Mainly I am looking to do this for code in my parent application, as it is available to the user. However, I want to limit what they can see.

There seem to be 2 paths, unless I am mistaken...

1. Utilize EditorBrowsable (EditorBrowsableState.Never ) attribute on members I would like to hide

OR

2. Catch the SyntaxEditorIntelliPromptMemberListPreFilter event and manually filter the list.

Option 1 is not optimal, as it affects my own development in the parent application. I would like to see my members.
Option 2 I have no idea how to use. It looks like I get a VBContext object passed as an argument, but I'm not sure what to do with it.

My optimal solution would be to have a custom attribute, like BrowsableInSyntaxEditor(false), that I could append to my memebers. It would be nice if the SyntaxEditorSoftware namespace came with such an attribute that the .NET languages Add On was setup to look for.

So, assuming I create my own custom attribute to place on members I don't want the end user to see... how can I use Option 2 to get this information out of the VBContext that is passed?

Any help, or at least a nudge in the right direction would be very much appreciated.

KB

Comments (3)

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

Kevin,

You are correct, those are the two ways to filter things out. The DotNetContext you get has a lot of information in it. The most important being the Items collection. Each DotNetContextItem object provides a Type saying what it is (namespace, type, member, etc.) and you can get the resolved info from the ResolvedInfo property.

So if your context is for a type reference "System.Text.StringBuilder", you'd have 3 items. The first two would be namespace types with their resolved info being the namespace names. The third item would be a "type" type and would contain an IDomType referencing info about the actual StringBuilder type. Keep in mind that you should always be checking for IDomType and IDomMember implementations instead of ClassDeclaration, etc. since the two interfaces handle both types/members from assemblies as well as from those defined in source. Also do null checks for the resolved info in case something didn't resolve.

Now if your types will ONLY be referenced via source project content and won't be loaded via an assembly, you could use a little trick. Right now the code is just looking for an EditorBrowsable attribute but isn't qualifying its namespace. So you could put one in that is in another namespace and that would probably work. However when loading assemblies (via external references) it will qualify the namespace.

Actipro Software Support

Posted 15 years ago by Kevin Bennett

I am not fully understanding...

I get the items collection from the VBContext. I see that each item does indeed have a type enumeration, but the ResolvedInfo property does not contain an IDomType. It seems to contain a type Addons.DotNet.Ast.VariableDeclarator. How do I get an IDOMType from the VariableDeclarator?

Essentially what I'm looking for is a system.type of the object whose member list is about to show. Is there a generic way to get this system.type?

Thanks,
KB

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

I'm not sure how you are getting that. When I run our sample and declare a local variable x then type "x.", I check the context and the item has a ResolvedInfo that is an IDomType. Maybe make a simple sample showing what you are doing and email that over and we can look on Monday. Thanks.

Actipro Software Support

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

Add Comment

Please log in to a validated account to post comments.