Hi,

First of all congratulations on getting v1 out. It's looking pretty cool!

I have been trying to migrate a DSL I developed in the June CTP version, but I have run into some errors. A couple of examples are..

Error 23 A GeometryShape may not be parented on a GeometryShape. In the ShapeMap mapping State to StateShape, the parent element path leads to StateManager, whose mapped shape is StateManagerShape.

Error 26 A ImageShape may not be parented on a GeometryShape. In the ShapeMap mapping EnterCommand to EnterCommandShape, the parent element path leads to State, whose mapped shape is StateShape.

Basically my DSL is similar to UML statechart notation, but I want to be able to nest states inside one another hierarchically in the diagram. I have embedding relationships among the classes in the definition, and the classes are being mapped to GeometryShapes and ImageShapes variously.

This was all working fine in the June CTP version, but the error messages would seem to suggest that in v.1 you can't have a geometry shape inside another geometry shape. That would seem to be a pretty arbitrary restriction to bring in, as embedding shapes like that is very often the most natural way of expressing an embedding relationship amongst concepts.

I hope that I am missing something.

Is there another way of getting shapes to nest inside one another in the new release?

Thanks,

Chris

Hi Chris,

Unfortunately there are quite a few areas of shape embedding that don't actually work quite correctly our of the box for V1 (and indeed since June) so we took the decision not to support shape embedding in V1 and put in the error messages you're seeing.

That's a shame. Will this functionality get fixed up for a future release? If so, any idea when that might be?

In the meantime, I've discovered I can get by to some extent by parenting the shapes to a "root" container that is either a swimlane or the diagram itself. The shapes are not actually embedded but you can put them on top of each other so that one appears to be inside the other - not ideal, but it'll do for now.

This raises another problem though:

The Parent element path is easy enough to define when you know how many levels deep your class is embedded. However I was aiming to design a language where a class could be embedded inside an instance of itself, so that you could have as many levels of embedding as you liked. This was fine when the parent element was simply the container of that class, but now it has to be an indeterminate number of steps up the tree.

I'm not sure if the path syntax supports anything other than defining a relative path from the current class, with a fixed number of steps. What I would need would be an "absolute" path, starting from the top level of the diagram.

You could draw an analogy with file system path syntax: a relative path is something like ..\..\windows\system32, whereas an absolute path is C:\windows\system32 . XPath also has something similar.

There's no mention of anything like this in the documentation, so I'm guessing you can't do this, and I'll be stuck with defining fixed levels of embedding. Am I right?

Thanks,

Chris

Chris,

If you look at Example.Components - look up the sample in the VS SDK Samples Browser or find it in somewhere like Program Files\Visual Studio 2005 SDK\2006.09\VisualStudioIntegration\Samples\DSLTools\Example.DesignerCustomizations\Example.Components - you'll see a fair simulation of what you want. There's a description of it in Program Files\Visual Studio 2005 SDK\2006.09\VisualStudioIntegration\Samples\DSLTools\Example.DesignerCustomizations\Example.DSLCustomizations.doc

Alan

That's cool - It looks to do just what I was hoping, although there's quite a bit of extra coding involved.

Also, given that the visible embedding relationships between components don't actually correspond to embedding relationships in the model that you create, it would make it a bit messier when it comes to traversing the model in templates.

It's a good workaround for the time being, though.

Certainly better to have something usable than worry too much about the purity of the model corresponding to the diagram.

Thanks a lot!

This workaround is also good..

Thanks very much for the suggestion Jan.

I had to bite the bullet and learn how to code some editor customizations, but it was easier than I expected.

Here's a bit more detail for anyone else who wants to try this out..

First, it would be a good idea to read the document Example.DSLCustomizations.doc which you should find in the folder 2006.09\VisualStudioIntegration\Samples\DSLTools\Example.DesignerCustomizations

This gives you the background information that you really need to know before you attempt this, and tells you how to do all kinds of interesting stuff besides.

The steps you need to do the shape embedding are:

1) For each shape mapping where you want to embed a shape inside another one: select the mapping, go to the DSL details window, select the "Has custom parent element" checkbox, but NOT the "Has custom parent shape" checkbox. Also, delete anything that you have in the "Parent element path" box, or you'll still get validation errors.

2) Select the Diagram shape from the Diagram Elements area of the designer, and in the Properties window set "Generates Double Derived" to True.

3) Save your DslDefinition and press the "Transform all Templates" button on the Solution Explorer - you should get no errors.

4) Find the Diagram.cs file under Diagram.tt in the GeneratedCode folder and open it. You should be able to find some calls to methods called GetParentForXXX (where XXX is the name of your element). These methods don't exist yet, and you have to code them manually. If you can't find these calls, try to build your solution and you should get a compile error for a missing method for each shape map that uses a custom parent element. You can double-click the errors and it will locate the calls to those missing methods.

5) Create a new code folder called Custom, and add a new .cs file. The name of the file doesn't matter, since it will contain a partial class or classes - it doesn't have to match the name of the class. The easiest thing to do is to copy and paste the partial class declaration from the partial class FixUpDiagram in Diagram.cs into your new file. Also, get the 3 "using" directives at the top of the file. Delete the metadata tags above the class declaration: You only have these once even though the class is spread across multiple files.

6) Code the GetParentForXXX methods. They should have return type ModelElement and take a single parameter of the type you are dealing with (i.e. XXX). You just have a single line in each method to return the parent that you would expect to have for that entity. e.g. If you have an entity called ModelClass which is embedded in an entity called ModelRoot, and the role name for the containing relationship is also ModelRoot, your custom GetParent method would look like:

DslModeling::ModelElement GetParentForModelClass(global::MyCompanyName.MyDSLName.ModelClass myNewClass) {

return myNewClass.ModelRoot;

}

7) Now you should be able to build and run your project with no errors.

Despite warnings of bugginess with embedded shapes I haven't yet experienced anything that would make me want to avoid using this functionality.

I'm sure there are some problems there or the DSL tools team wouldn't have made it so hard to do it!

(that could be interpreted as an invitation to elaborate on what the issues are exactly.. ;)

Chris, it's not the embedded shapes per se that are buggy, rather it was our ability to get in a full feature set around modeling and generating the code you're currently hand-writing.

There are some issues around line routing between embedded shapes that are cousins of each other (i.e. their parents are peers but the routing crosses embedding boundaries).
There are also two types of embedding supported by our diagram surface - nested and relative - See NodeShape.ChooseRelationship and various overides such as
AllowsChildrenToResizeParent and AllowsChildrenToShrinkParent that you need to consider.

Also, as you say, there are issues around needing different paths when embedding is sometimes reflexive and sometimes rooted.

Perhaps, originally I should have said that nested shapes were not supported in V1 without writing some custom code.