Auto-Complete/MemberList functionality for ANSI C language

SyntaxEditor for Windows Forms Forum

Posted 7 years ago by Stepan Protsak
Version: 12.1
Avatar

Greetings!

Our application provides editor for ANSI C language, which is currently implemented using Actipro SyntaxEditor v4.0.Right now we are supporting syntax highlighting and automatic outlining. This was implemented based on “ActiproSoftware.C.xml” lexer and “CSharpDynamicSyntaxLanguage.cs” sample.

Now we need to extend our editor with Auto-Complete/MemberList functionality. We’re very limited in time frame, so we need to choose the simplest and quickest way to do that and we need to estimate the effort required.

Right now I see the next possible ways:
1. Continue to use dynamic language described in “ActiproSoftware.C.xml” + extend “CSharpDynamicSyntaxLanguage.cs” class for member list support.
In this case I’m predicting a lot of non-trivial coding in “ShowIntelliPromptMemberList” method.
2. Utilize and extend simple add-on.
In this case I’m predicting a lot of work to do in the grammar definition xml (ActiproSoftware.Simple.Grammar.xml).
3. Utilize CSharp add-on code (we have blueprint license purchased for this).
In this case I suggest we need to modify this add-on to eliminate a lot of excessive code.

Can you, please, suggest the way and starting point for us to move forward?

Thank You!

Comments (14)

Posted 7 years ago by Tobias Lingemann - Software Devolpment Engineer, Vector Informatik GmbH
Avatar

I don't think any of these options will do it. Doing context sensitive intelli prompt like in C# is a lot of work.
I would suggest you start with basic intelli prompt feauters that are not context sensitive. Just put all members and functions in a long list and show all of them. Private members or functions can easily be identified using the file name.

If you could find a parser that you could use, that would be perfect. I dont know if you can exctract the AST from the GCC, but since it is Ansi C I am pretty sure there will be a suitable parser out there. Based on the AST you can create your own intelli members.


Best regards, Tobias Lingemann.

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Stepan,

Since you already have licensed the .NET Languages Add-on source code, I'd actually probably recommend starting with that and then trim everything out that you don't need.  Its grammar is already going to be relatively close to what you need for ANSI C and it's probably much easier/faster to subtract things away and tweak, than write from scratch.


Actipro Software Support

Posted 7 years ago by Stepan Protsak
Avatar

Thanks for the answer!
I've already started with approach similar to what is used in XmlSyntaxLanguage.
But since I'm facing bunch of issues (some I've resolved, some still need digging in code as the documentation is not clear enough), I'll probably switch to trimming of .NET Languages Add-on.

Is there is something special I should know about reusing the code of this add-on talking about license nuances?
1. Can I compile it in separate dll / can I embed it in my existing dll?
2. Must I use obfuscation?
3. Can I change Namespaces to reuse my own instead of ActiproSoftware.SyntaxEditor.Addons...?

Thank You!

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

Hi Stepan,

Yes you can embed the code in your existing .dll.  I believe you'll find all of your questions answered from the information in the EULA that comes with the product, in the section where it talks about source code.


Actipro Software Support

Posted 7 years ago by Stepan Protsak
Avatar

Can you, please, clarify the main two items for me?


Per this document the main points for me are:
1. I need to obfuscate the code even if it included in my own assembly, right?
Just if it will not take too much time for you - can you, please suggest the right tool for me?

2. I need to keep original namespaces, right?
This is quite inconvenient for me because of:
a. I’m integrating CSharp add-on code into my own assemble and would like to keep namespace structure as clear as possible;
b. It is very possible that in nearest feature we will need to parse C# language syntax and utilize all power of the SyntaxEditor.Addons.DotNet for that. In this case we’ll have issues with resolving namespace names duplicates. Is there any way where I can use my own namespaces?

Thank you for support and sorry if my questions looks silly – just want to make things right?

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Stepan,

Thanks for checking, we appreciate your questions.

1) Yes, we use SmartAssembly from Red Gate.

2) In this case, we can give you an exception on the namespace since you are using the add-on's code more as a guide and starting point for your own language than using it directly.  So go ahead and place the code in your own namespace.


Actipro Software Support

Posted 7 years ago by Stepan Protsak
Avatar

Thank You for quick and patient answers!

Nice support!

Posted 7 years ago by Stepan Protsak
Avatar

One more similar question, if you don't mind:
Taking into account all said and all statements from post#1, what approach would you recommend for implementing Auto-Complete/MemberList functionality for Assembler language (as much as the syntax of assembler language used for microcontrollers can allow)?

Maybe as one additional possible way to go, I would add approach used for XmlSyntaxLanguage.

Can you suggest the way you would go yourself for such task?

Thank You!

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

Hi Stepan,

If you are making something brand new like an Assembler language, then you probably would want to start from scratch.  First build the lexer programmatically and get all the syntax highlighting working.  Then build a grammar and parser that can return an AST and report/display syntax errors.  Then based on token scanning and AST, implement your IntelliPrompt display.

I'm not all that familiar with Assembler however if it doesn't really use a tree structure (and is just a long list of "statements" or operations), then perhaps building a full grammar isn't needed and you could possibly get away with just doing token scanning for determining what to show in IntelliPrompt.  That would make it easier and faster for you to develop the language.


Actipro Software Support

Posted 7 years ago by Stepan Protsak
Avatar

I heard that the "Syntax Editor Language Designer" in WPF bundle can simplify the work a lot. Is there any way we can utilize its possibility to construct a grammar for SyntaxEditor v4.0?

Thanks again!

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

Hi Stepan,

Unfortunately that won't work since the Language Designer is for the WPF and Silverlight versions.  Its output isn't compatible with the WinForms version.  Also the newer grammar engine in those platforms is completely different than the WinForms one.  Eventually we hope to backport all the newer designs to WinForms so that all three platforms can be on the same general codebase.


Actipro Software Support

Posted 6 years ago by Stepan Protsak
Avatar

Greetings!
As per original question and your reply in third post, I was started implementation of ANSI-C language parser using .net add-on’s for SE4.0 code as starting point.

Since the portions of original code where minimized and refactored just for simple C language support (I believe about 10%-15% of original code left and these parts was trimmed and refactored a lot), here is the question: Do I still need to obfuscate the output dll?


Thank You!

Answer - Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Stepan,

Thanks for checking.  If that is the only amount of original code left then no, don't worry about that requirement.


Actipro Software Support

Posted 6 years ago by Stepan Protsak
Avatar

Thanks!

The latest build of this product (v2020.1 build 0400) was released 5 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.