CodeDOM support

Hi Alex,

No it doesn't currently translate over to CodeDOM. However it wouldn't probably be all that difficult to write a converter that takes our CompilationUnit (stored in the Document.SemanticParseData property of a C# document) and write out a CodeDOM tree from that. We don't have any immediate plans to do so but if you end up working on it, please let us know as we'd be interested in the result.

Thanks for the reply. I looked into the Add–in documentation and the CodeDOM generations don’t look too difficult. We can use visitor pattern and create CodeDOMVisitor to traverse the CompilationUnit tree.

So far I don’t have an urgent need for this feature, but it is definitely in our list of features to have. You see, any developer who try to reuse Windows Forms Designer and the new Workflow Designer will need to parse the code in order to generate the CodeDOM. In .NET there is a class CSharpCodeProvider with has method “Parse”, but this method “is not implemented” in the standard .NET classes but exist only in VS implementation. Currently I see a huge interest in re-hosting the WorkFlow foundation designer in user application. It works in simple cases, but to build a complete solution with full code-beside support a nice source editor with CodeDOM parse support is required. I think that your control can feel this gap and be the only one source editor which can be used in conjunction with .NET designers.

Are there any chances that you might implement this feature in the nearest future?
Thanks

Right now our top priority is getting v4.0 out of beta. Then we need to focus on a VB.NET implementation for the .NET Languages Add-on.

Could you go into a little more detail on how CodeDOM is used with your scenario. Like do you simply want to be able to write out C# or VB.NET code from a compilation unit or do the designers you are talking about actually require use of the CodeDOM classes? Any links to more info on these designers would be helpful too.

I will reply, with my best.

In VS you can draw or design forms. You can also use tools in .Net to do this very same thing in your own app. You can draw a form with controls and output a System.CodeDom.CodeCompileUnit and then VB or C# code via System.CodeDom.Compiler.CodeDomProvider. The only problem is that .Net doesn't provide any means to parse a VB or C# file back into a CodeCompileUnit. You need this CodeCompileUnit to open a form designer with previously created work. As of now with just .Net you cannot load designer code into a designer for editing only extract the code.

I think with your parsing into a CompilationUnit you could translate it into a CodeCompileUnit and fill the .Net gap. It would make my life easier.

As of now I use two libraries from http://www.icsharpcode.net/OpenSource/SD/ NRefactory and ICSharpCode.SharpDevelop.Dom to fill the gap.

Maybe if you are able to create this CodeCompileUnit you can then spend a little more time gluing together all the parts .net provides to create a form designer control that is an addon for your SyntaxEditor and sell the clean package. It took me probable 100 hours to implement a form designer with toolbox, properties view and solution explorer.

I have been working with this stuff for some time now I am not an expert but if you have any more Qs let me know. I also don’t mind sharing code.

Leif Zars

I looked into SharpDevelop NRefactory, but found it very limited. It supports only things required for Windows.Forms designer. That's why I spent some time and created my own CodeDom parser using Actipro CompilationUnit (as was suggested by the support). It turned out to be relatievly easy. Also, since we need to create CodeDom only for class and methods declarations, I don't traverse into methods implementions at all, but just create CodeDomSnippetStatement using method body. It works very well and I don't need to depend on SharpDevelop. I still have a few problems with comments - it looks like the CompilationUnit doesn't capture them correcly, but I can leave with it.

It would be great if someone in Actipro can take into this CodeDOM support. You guys already have everything to create an excelent CodeDom parser and it will bring additional value to your product. Especially now, when you have VB!!!

Alex

I just need form designer support for now but in time i might look in to doing that.

but i don't want to lol sounds like a lot of code.

:)

Thanks
Leif

Alex,

I have decided to work on an Actipro CompilationUnit to CodeDom parser. Can you offer any design patterns, source or tips since you have already worked on this.

Thanks

Leif

We don't have the time right now to write all of this ourselves but we can possibly help collaborate with you both on this if that's something you'd like to do.

Dear Leif,

I have been trying to do the same as you are doing. I have found that the only way of getting a standalone form designer, is by using the DesignSurface class (with a CodeDomDesignLoader). However, it indeed needs a parser to work with. There are a couple of parsers (NRefactory, Visual Studio, CodeRush and ActiPro's). I haven't been able to get a working instance of the Visual Studio and CodeRush ones, as these are integrated in the VS IDE. NRefactory works, but it is very primitive and you'll need to adhere to their member resolving classes. So I tried ActiPro...

While using the AstVisitor, you can visit every astnode in the tree. First, you will need to catch the CodeTypeDeclarations:

- ClassDeclaration (the class of the current file)
- MethodDeclaration (the InitializeComponents method)
- FieldDeclaration (the components etc)

Add those to your variable CodeTypeDeclarations.
Then... visit all expressions and add them to a codestack (codeStack As New Collections.Generic.Stack(Of Object)), while poping and pushing (accordingly to the current level you are visiting. This will result in correct parenting).
Now add that stack to the method, your class to a namespace, and your done!

Currently the sourcecode is outputting correctly (so, almost done!), but there is one problem: ActiPro only visits MemberAccess, while the CodeDom separates them in Field/Property/Method. So, while visiting the MemberAccess node, I need to determine whether the member is a field, property or a method. Currently, I haven't found a way to do this. I asked ActiPro... they replied with:

Quote:
That's a bit tricky. IDomMember is the interface for member declarations.
MemberAccess is not a member declaration, rather it is the calling of a member declaration for execution. So you must resolve the Expression into a type and then search for a member on that with the MemberName. Your best bet if possible is to get a context at the offset at which the member name ends since that should execute the very complicated code that we have to try and convert an expression into a reference.

To be honest, I still don't know how to implement the code. Do you perhaps know how to do this?

Greetings,

Michel

I currently have a parser using NRefactory working but with a few limitations. But if you need any help with the designer part I have been very successful in getting 90% of it functional, even the auto event creation.

In using Actipro I see what you are saying and it sounds good. I will be taking a look at the AstVisitor shortly.

I see the problem you are having with the MemeberAccess. Basically if ‘A’ is an object and ‘B’ is a member we need to find out if it is a field, method or property. I would imagine that you should be able to determine the type of A and then search it for a member with the same name a ‘B’. Then you will know what kind of member you are looking at. But I have no clue what Actipro is talking about with “get a context at the offset at which the member name ends”.

It might be a few days before I take a serious look at Actipro for this task but I will let you know how it goes.


Leif

To get a context, that means this sort of code: In this case you would pass the Document, the offset in the document where the member's name starts, the CompilationUnit, and the DotNetProjectResolver.

Now that you have a context, it will contain information about what is there. If you look at the items of the context and if it was able to resolve to type/member data, the IDomType and IDomMember objects will be available in properties of the items of the context. From IDomMember you can get a member type (method, property, etc.).

Hope that helps.

Dear ActiPro, you are indeed correct! Thanks for solving that issue. However, I bumped onto another issue:

While inside the MemberAccess function and evaluating the following line of code: The value of node.MemberName.Text returns "Button1" as expected (as the member's name is indeed Button1!). However, while executing your code, I didn't get the correct context. So, I tried doc.GetSubstring(node.MemberName.TextRange), which should return "Button1" aswell (IMO). Well, it doesn't; it returns "= New S". So, I think the context is resolving "= New S" instead of "Button1", and therefore returning an incorrect context. If I move the offset with some position to left (so that doc.GetSubstring(node.MemberName.TextRange) = "Button1"), I do get the expected Context. So, I am doing something wrong here, or did I just find a bug :) ?

Hmmm... it could be a bug. I wonder if something is counting the CR/LF instead of just LF as a line terminator. Is the number of offsets that it is off by, the same number of lines down from the top?

Yes, it is!

[Modified at 04/10/2007 09:32 AM]

Michel,

There's got to be something else going on here because the TextRanges should be based on LF-only line terminators and at least from looking at our code, that's what it appears to be doing. Otherwise, the syntax error indicators would be offset as well.

Can you throw together a tiny sample project and send it over that shows this issue maybe with just a couple of C# code being edited in SyntaxEditor? This way we can debug it. Thanks!

Ah... while I was making a little sample for you to debug, it magically start working! First I used the semantic parse service to create a compilationunit. Now, I am using the parse data from the document, which seems to work a lot better!

So it's working ok now?

It is indeed working now! Thanks for the great product and the great support!
PS: I wondered if you also have some kind of student subscription for your products?

Hi Michel,

We can work out a student discount if you can provide current transcripts from your school.

Michel, would you be willing to share some or all of your work in this area?
Let me know

leif@leifzars.com

Thanks Leif Zars

Hi Support,

Does Grammar.xml helps in here for converting
from CompilationUnit -> CodeCompileUnit ?

we are looking more insite in Grammar so that we can directly map the grammar and just apply the xml.


Let me know.
thanks!

Sorry it doesn't support that at this time. We may look into adding something like that in the future.

any other quick way of converting from ICompilationUnit to CodeCompilationUnit?
tips/tricks/suggestion etc.?

You could perhaps use the visitor pattern as mentioned in previous posts to iterate down nodes and convert as you go. But we haven't tried this ourselves. I think some customers may have though.