Workaround for Known Issue with TypeDescriptors in DSL Tools for Visual Studio

Tags: , , ,
No Comments »

There is a known issue in the current version of the DSL Tools while dealing with custom TypeConverters or custom TypeDescriptors:

1.10 TypeConverters and TypeDescriptors are not picked up during the build process or during toolbox initialization.
When adding a custom TypeConverter or TypeDescriptor and then building the DSL, the TypeConvertor or TypeDescriptor is not picked up. The workaround is to rebuild the solution with a clean build.

[see Known Issues for Microsoft Visual Studio 2008 SDK 1.0]

Some time ago I posted a workaround for this problem with the TypeConverter, but today a realized that this workaround does not work with the same issue for TypeDescriptors.

Imagine some class with the following attribute:

[TypeDescriptionProvider(typeof(MyClassTypeDescriptionProvider))]
public partial class MyClass : ModelElement
{}

The corresponding TypeDescriptor (provided by the MyClassTypeDescriptionProvider class) is loaded only the first time you build or rebuild your solution. Every time you start Visual Studio after that, this attribute seems to be ignored.

Fortunately there is another way to glue TypeDescriptors to your classes using a static method of the TypeDescriptor class at runtime:

TypeDescriptor.AddProvider(
   new MyClassTypeDescriptionProvider(), typeof(MyClass));

I think a good place for this code is the static constructor of the MyClass type:

partial class MyClass
{
    static MyClass()
    {
        TypeDescriptor.AddProvider(
            new MyClassTypeDescriptionProvider(),
            typeof(MyClass));
    }
}

Another interesting point is: Not only custom TypeDescriptors you write yourself are affected by this problem, also the TypeDescriptors that are generated by the DSL-Tools from your DslDefintion have to struggle with it:

In the DSL Explorer you can define custom TypeDescriptors for each Domain Class and each Shape. Even these TypeDescriptors will not be loaded after the first run. In other words: the definition of TypeDescriptors in the DSL Explorer is pretty useless as long as you do not add the three lines of code to each class. Of course this is something one can automate! 🙂 I stole some code from PropertiesGrid.tt and added a few lines to create the RegisterTypeDescriptor.tt. Just add this file to your Dsl Project in the GeneratedCode folder and all TypeDescriptors defined in the DSL Explorer will be loaded every time you start your project.

Even CodeVeil has bugs

Tags: , ,
No Comments »

I love CodeVeil. From my point of view CodeVeil is simply the best tool to protect .NET assemblies from being reflectored, decompiled or whatever. It is very powerful, offers a wide range of protection aspects and still comes with a handy gui. So far I haven’t seen a method to crack veiled assemblies and that’s why I really rely on it for my commercial products.

You don’t find bugs in CodeVeil when you try to find them, but half a year ago we found this one by chance. CodeVeil veils well, but the resulting code throws a mighty exception.

You don’t need spectacular code to lure the bug out of it’s hole – here is the prelude:

private static void Main(string[] args)
{
    // Get list and fill it with values
    List<Capsule<int>> l = new List<Capsule<int>>();
    l.Add(new Capsule<int>(23));
    l.Add(new Capsule<int>(42));

    // Have it sorted
    List<Capsule<int>> l2 = GetSortedReturnList(l);

    // Show result
    foreach (Capsule<int> ci in l2)
        Console.WriteLine(ci.Item);

    Console.ReadLine();
}

A simple list of two ints that are encapsulated in a generic type. The generic type just makes sure that two items can be compared:

internal class Capsule<T> : IComparable<Capsule<T>>
{
    public T Item;

    public Capsule(T i)
    {
        Item = i;
    }

    public int CompareTo(Capsule<T> other)
    {
        return Item.ToString().CompareTo(other.Item.ToString());
    }
}

And this code causes the exception when being executed by the veiled assembly:

private static List<Capsule<T>> 
    GetSortedReturnList<T>(List<Capsule<T>> list)
{           
    int sortOrder = 1;
    list.Sort(
        delegate(Capsule<T> a, Capsule<T> b) 
          { return sortOrder * a.CompareTo(b); });

    return (list);
}

The sore point is the sortOrder variable being multiplied with the result of a.CompareTo(b) used in an anonymous method. Okay, you wouldn’t expect this code from a beginner, but it’s not rocket-science either. So we were very astonished and it took us quite some time to track this down and to believe our eyes. Maybe the problem with CodeVeil is related to the internal representation of anonymous method. When you use a constant instead of a variable

const int sortOrder = 1;

the problem disappears. I guess the compiler eliminates the constant and CodeVeil will not see it. But it remains, when you use a Linq-notation here:

list.Sort((a, b) => a.CompareTo(b)*sortOrder);

As said before we found this bug half a year ago. We contacted Xheo and received a very quick and friendly reply, but no solution. Seasons went by and several new versions of CodeVeil were released; but this bug is still present. At least in the stand-alone version.

But there is hope: The new beta preview of the DeployLX suite contains an obviously new version of CodeVeil and the bug is finally gone. And – by the way – this new version seems to offer a nice package of new feature and improved power! So, please, Mr. Xheo, release a new stand-alone-version of CodeVeil based on the new beta preview!

Where can I find the model filename in a text template (tt)?

Tags: , , , ,
No Comments »

As you know I was working with the DSL Tools in the past months. For some weeks I am writing the code generation for my project and I am struggling with new problems.

For some reason I want to know the filename of the model used in the tt-file. The default implementation provides you only with a reference to the model but with no chance to get its filename.

In your tt-file you will find something similar to

<#@ Language15 processor="Language15DirectiveProcessor"
     requires="fileName='Sample.mydsl1'" #>

This will use the Language15DirectiveProcessor to load the given file and provide your template with a global ExampleModel variable (of cause the name depends on your DSL and you can change it with the provides attribute in the tt-file).

To change the Language15DirectiveProcessor you can create a partial class in your DSL and add some code to it:

partial class Language15DirectiveProcessor
{
    protected override void GenerateTransformCode
     (string directiveName,
      StringBuilder codeBuffer,
      System.CodeDom.Compiler.CodeDomProvider languageProvider,
      IDictionary<string, string> requiresArguments,
      IDictionary<string, string> providesArguments)
      {
        base.GenerateTransformCode(directiveName,
                    codeBuffer, languageProvider,
                    requiresArguments, providesArguments);           

        codeBuffer.AppendFormat(
           "public string {1} = @\"{0}\";",
             requiresArguments["FileName"],
             providesArguments["FileName"]);
       codeBuffer.AppendLine();
    }

    protected override void InitializeProvidesDictionary
    (string directiveName,
      IDictionary<string, string> providesDictionary)
    {
        base.InitializeProvidesDictionary(directiveName,
                            providesDictionary);

        providesDictionary.Add("FileName","FileName");
    }
}

This adds a new global variable FileName to the tt and initializes it with the model file name.

Attention: You see the variable in this example is generated by writing a line of C# code to the codeBuffer. This may be a bad idea if you want to use this DirectiveProcessor for templates where the template language is set to VB. The better way is to create the code using the Emit and CodeDom API, but I was to lazy to do it that way.

If anybody ports this code to work with VB templates by using the CodeDom or plain VB code, please post a comment here.

Further reading: The process of creating your own DirectiveProcessor and everything you need to understand the code above can be found in the msdn: Creating Custom Text Template Directive Processors.

Visual feedback for black connectors on mouse over

Tags: , , ,
No Comments »

One of my DSLs uses many black connectors laying all over the screen. Every time I try to follow one connector I select it to change the border and to see a difference between all connectors. A colleague saw this design and asks me to implement a mouse over feedback for these connectors since all shapes have already such a visual feedback. The color of shapes changes a little bit if the mouse is over the shape. I had no idea how this should work for connectors…

First I take a look on the properties of the connector in the DSL designer and while searching I observed something: The DSL designer has this behavior on all connectors! I don’t have to write code for the MouseOver-event, but I have to figure out how to activate this behavior on my DSL editor.

For my surprise, the connectors on a newly created example language have a mouse over feedback, too. After playing around with some properties I was faced to a interesting fact: The mouse over feedback works pretty good for all connectors but black ones. I had no idea what’s going on.

Long story short: With Reflector I found one interesting method in the ShapeElement class: ModifyLuminosity(). The documentation is very clear:

"Calculates the luminosity of the highlight for the shape."

"The formula that creates luminosity. By default, the formula is: if luminosity is >= 160, then luminosity = luminosity * 0.9; otherwise, luminosity = luminosity + 40."

The luminosity of a black connector is 0 so the new luminosity will be 40. But for the color black you hardly see a difference between 0 and 40. But with this knowledge you can override the method in the connector class like this:

protected override int ModifyLuminosity
              (int currentLuminosity, DiagramClientView view)
{
  if(!view.HighlightedShapes.Contains(new DiagramItem(this)))
     return currentLuminosity;
        
 return 130;
}

The value 130 on a black connector works pretty good for me. Just try a few values und find a value you like.

HighlightedConnector

Asymmetric encryption / public key encryption / RSA

Tags:
2 Comments »

It took me a lot of time to find a neat explanation of asymmetric encryption. Many sides say “a message is encrypted using a public key and it can only be decrypted with a corresponding private key.” Okay, fine, but how does it work in detail? Finally I found the RSA-entry in wikipedia. It’s almost what I was looking, but there are still lots of links to mathematical definitions and calculations you can’t do with your pocket calculator. So I decided to write a little compilation of the presented algorithm and to apply it using numbers you can handle. Also small number help to clarify things – but keep in mind that all the numbers are much much much greater in serious encryption.

How do we get our private-and-public-key-pair?

  1. Choose two distinct (large) random prime numbers p and q
    p = 7,   q = 3.
  2. Compute n = p*q. This n is used as the modulus for both the public and private keys
    n = 7*3 = 21.
  3. Compute the totient: phi(n) = (p-1)(q-1)
    phi(21) = (7-1) * (3-1) = 12.
  4. Choose an integer e such that 1<e<phi(n) and that e and phi(n) share no factors other than 1 (i.e. e and phi(n) are coprime.). e is released as the public key exponent.
    In order to chose an e I will factorize my phi(12) first: 12 = 2*2*3.
    I chose e=5. e does not necessarily have to be prime but it makes it easier to avoid sharing a factor.
  5. Compute an integer d to satisfy the congruence relation d*e mod phi(n) = 1; d is kept as the private key exponent.
    “congruence relation” sounds more complicated than it actually is: Take two different numbers and apply the same modulo-operation to them (like mod 3). If the result is the same for both you may call your integers congruent modulo 5.  Like 11 and 16 are congruent modulo 5, since 11 mod 5 = 1 and 16 mod 5 = 1.
    So we are looking for a integer d that fits into
    d * 5  mod 12 = 1.
    I needed some tries here and wrote some lines to find the lowest d = 5. With one d found you can find all but just adding 12 :-). I didn’t want to take 5 as the private key exponent, since having the same exponent for encryption and decryption is… well… stupid. So I’ll choose 17.
    17 * 5 mod 12 = 1.
    85 mod 12 = 1.  Correct!

Do we have our private and our public key now? Yes, we have. Note that a key is not one single number but a pair of two numbers. Both are needed in the processes of encryption und decryption. One is the exponent and the other the modulus. Just a second and you’ll see why.

public key: e =5 (exponent) / n = 21 (modulus).

private key: d = 17 (exponent) / n = 21 (modulus). 

Let’s encrypt something

We have given our public key to anyone we know. And we kept our private key hidden somewhere under the bed. Now a beautiful and clever girl named Alice wants to send me a message. Fortunately the letters of her message can be represented as a stream of bits and we interpret this stream as a number. So her message is 10. It is important that her message is lower than our modulus, we’ll later see why. Let’s call her original message m and the encrypted message c.

m=10

The encryption it a simple formula: c = m^e mod n.

c = 10^5 mod 21

c = 100000 mod 21

c = 19.

So Alice hands me a little note saying “19”. 19? What the hack is that supposed to mean?

Now the magic happens

I rush back home to find my private key and apply it to “19”

The formula for the decryption look very similar: m = c^d mod n.

m = 19^17 mod 21.

m = 5480386857784802185939 mod 21. (Try it using calc.exe)

m = 10!

 

Wow! Alice says “10” to us. Isn’t 10 the international code for “I would like to date you?” I think so.

 

Signing

To encrypt with the public key means you can decrypt only with the private key. The converse is also true – to encrypt with the private key means you can decrypt only with the public key. Try it!

How can utilize this? We can use it to guarantee that a message is from a specific sender.

I have been dating Alice for some time now and we are used to leave messages to each other at a hidden place. Unfortunately another girl – Eve – is very jealous and has spied our secret mailbox. One week ago she found a message from Alice to me. She couldn’t read it, but she threw it away and replaced it by a mean offense against me. She encrypted it using my public key (which is public 🙂 ) and I thought it was written by Alice. The message started a little fight but luckily we found about Eve’s intention and started signing our messages. Now we transfer messages like this:

  1. Alice writes me a message m.
  2. She encrypts m using my public key, the result is c.
  3. Now she encrypts c using her own private key, the result is cs (c signed)
  4. She leaves me the message
  5. I decrypt cs using her public key, getting c. (Eve can do this as well – but that’s it. She can’t read c and she can’t leave me a fake cs because she doesn’t have Alice’s private key.
  6. I decrypt c using my private key and get back m – bingo!

 

Padding

Breaking this code (meaning “decrypt without having the private key”) is always a lot of work and hard trying. But is becomes much easier, when you know that m is short. That’s because you only have check that little fraction of configurations where m = c^d mod n leads to small ms. To avoid this small messages are artificially made longer until they are close to n. That process is called padding and even padding can be a tricky task.

Last question

We know what happens to short messages. But what happens to long messages? It is obvious that messages – seen as a number – can’t be greater than n-1, since the mod n – part of the decryption formula will never return values >n-1. I guess the message is split up in parts, but couldn’t find a satisfying answer. If I do, I’ll let you know.

 

Take care, 
Bob

msi-installer and RemovePreviousVersions-option fixed in Visual Studio 2008

Tags: , ,
1 Comment »

Visual Studio 2005 had a known issue with the setup project and the RemovePreviousVersions option if the version number of your software is less than 1.0. This was a problem for me every time I released a new version of PhotoTagStudio. Like most small open source projects I won’t call it 1.0 (the current version is 0.7).

I described the problem and a workaround using the tool orca.exe. Every time I build a new setup I had to patch the setup. Last week I switched my PhotoTagStudio project to Visual Studio 2008 and created a new release. While patching the created msi I discovered that there is no need to do it that way any more. The problem seems to be fixed in the Visual Studio 2008 release!

Great work Microsoft!

Custom restrictions for Domain Properties

Tags: , , , ,
1 Comment »

In To restrict dynamically the usage of Domain Properties in DSL Models I described a way to restrict the usage of certain domain properties by the user. You can define different modes for your editor and thus allow or prevent the usage of domain properties via attributes on your domain classes. The technique is described in the linked article and the code is released as part of JaDAL – Just another DSL-Tools Addon Library.

This is a pretty static way to control the domain properties. You have to define a few modes and decide at design time the visible and active properties for each mode. Sometimes you need a more dynamic way: So I introduced another attribute CustomRestrictedPropertyAttribute and an interface ISupportsUserRestrictions. If this attribute is present, the library will call the GetRestriction() method of this interface and your user code can decide whenever the domain property will be visible, hidden or read only.

I built a small example: a domain class contains a few properties: CustomPropery, CustomPropertyVisible and CustomPropertyReadOnly. The two flags cause the first property to be visible, hidden or read only in the properties window.

[CustomRestrictedProperty("CustomProperty")]
partial class ExampleElement : ISupportsUserRestrictions
{
    public Restriction GetRestriction(string property)
    {
        if (property == "CustomProperty")
        {
            if (!this.CustomPropertyVisible)
                return Restriction.Hidden;

            if (this.CustumPropertyReadOnly)
                return Restriction.ReadOnly;

            return Restriction.Full;
        }

        return Restriction.Full;
    }
}

properties

This example can be downloaded as part of the JaDAL source code. Currently you have to catch the code directly from the Source Code tab at CodePlex since it isn’t part of the latest Release yet.

JaDAL – Just another DSL-Tools Addon Library

Tags: , , , , ,
No Comments »

Over the time I build some libraries that enhance the Microsoft DSL Tools framework and post them here. I wrote a number of articles and for many of them I provided a download with source code or examples.

However we all know: zip files are a bad version management system!

I decided to put all these code together and compose a single library with addons for the DSL Tools, name it “JaDAL – Just another DSL-Tools Addon Library” and publish it at CodePlex. I will continue to write articles here, but now you can always find the latest code at CodePlex.

If you are interested in my work with the DSL Tools, just take a look at JaDAL.

Connectors between compartment shape entries with DSL Tools – Version 2

Tags: , , , ,
7 Comments »

Few months ago I wrote a series of articles and released a library to create connectors between the entries of compartment shapes in Microsoft DSL Tools. In the meantime I found a setting that wasn’t working with my library and now it is time for version 2. I will release this new version as part of JaDAL – Just another DSL-Tools Addon Library on CodePlex.

If you don’t have any idea what I’m talking about please take a look at (at least) the first part of the series, but be careful and DO NOT read the second part! The second part contains obsolete information that will be corrected here. Part 3 and part 4 describe the inside of the library and they are still valid for the new version.

sample

Changes from version 1 to 2

In the original version you have to decide (using the xml file) for the target and source of the connection to be mapped to a compartment or a regular shape. I thought this wouldn’t be an issue since you must know the mapping of your classes. I believed it until I created my DSL with the use of inheritance and some base class that can be mapped to regular or compartment shapes. For this base class I couldn’t create a mapping that goes from a regular or a compartment shape to a regular or compartment shape.

I removed this constraint and in version 2 you needn’t care about it. The library can handle all these cases (even the trivial mapping from regular to regular shape). And even the best: it turned out that removing this constraint made the code much clearer and simpler (both the code of the library itself and the code you have to write). Before this change there were many different cases (first regular to compartment, then compartment to regular, then compartment to compartment and at the end regular to regular which throws an exception) and now everything works the same way.

Lesson learned: If you can do something in an abstract and general way, don’t create different cases and handle only some of them!

And again: the user guide

In the 2nd part of this series I presented a user guide with a step by step walkthrough of creating a DSL using the compartment mapping. I will now create the same DSL with version 2. Most steps are still the same but I repeat them for completeness. The main difference is the xml file format at step 7 and the class you have to write yourself in steps 9 to 11.

You will find this example (and a more advanced one) in the release download over at CodePlex.

  1. You need TTxGen to generate some code from my templates. See my article for more information and a workaround for an installation problem.
  2. I assume you have a DSL solution and at least two Domain Classes mapped to two compartment shapes and two more Domain Classes used as entries of the compartment shapes created. In my example these classes are called Parent1, Entry1, Parent2 and Entry2.
    The entries need a unique identifier. You could use a name property for this, but there will be some difficulties if the user creates two entries in one shape with the same name, so I will use a guid. (Don’t forget to create a new guid in the constructor or another proper place.)
  3. Create a Reference Relationship from Parent1 to Parent2. This will be automatically named Parent1ReferencesParent2. We will use this reference to present the relationship from one entry to another. I would like to create Reference Relationships from this relationship to the entries, but relationships of relationships are not supported. We have to store the guids of the entries in the relationship and add two Domain Properties for this purpose to it. I named them fromEntry and toEntry.
    DslDefinition 
  4. Set the Allows Duplicates property of the Parent1ReferencesParent2 relationship to true.
  5. Set the Is Custom property of the Connection Builder (Parent1ReferencesParent2Builder) in the DSL Explorer to true.
  6. Add a reference to JaDAL.dll to both the Dsl and DslPackage project.
  7. Add a new xml file (in my example CompartmentMappings.xml) to your solution and write the following code in it:
    <?xml version="1.0" encoding="utf-8" ?>
    <CompartmentMappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="CompartmentMappings.xsd"
     namespace="BenjaminSchroeter.CompartmentMapping">
     
      <Connection name="Parent1ReferencesParent2" 
        allowSelfReference="true"
        suppressEntryDeletePropagation="false">
        
        <Source allowHead="false">
          <DomainClass name="Parent1" />
          <EntryDomainClass name="Entry1"/>
        </Source>
        
        <Target allowHead="true">
          <DomainClass name="Parent2"/>
          <EntryDomainClass name="Entry2"/>
        </Target>
        
        <Connector name="Connector"/>
      </Connection>
    
      <CompartmentShape name="CompartmentShape1"/>
      <CompartmentShape name="CompartmentShape2"/>
    </CompartmentMappings>

    (If you place the xsd file in the same directory you get IntelliSense and error checking for free.)

  8. Place the CompartmentMappings.tt file in the same directory, right-click on the xml file and choose Generate xGen Template. A CompartmentMappings_xGen.tt file will be created below the xml file and there you have to add the following lines:
    <#@ ParentFileInjector processor="TTxGenDirectiveProcessor" 
        requires="fileName='CompartmentMappings.xml'" #>
    <#@ include file="CompartmentMappings.tt" #>

    (Be sure you use the right xml file name here.)

  9. Now you have to write some code by yourself. In the generated cs file (CompartmentMappings_xGen.cs) there will be a class named Parent1ReferencesParent2BuilderInstance with three missing methods you have to override. Create a partial class in a new file and implement these methods (see 10 and 11).

  10. Implement the CreateElementLink() method in this file. Here you have to add code to store the selected compartment entries for source and target in the properties of the relationship (see 3).
    protected override ElementLink CreateElementLink
        (Parent1 source, 
         SelectedCompartmentPartType sourcePartType,
         Entry1 sourceEntry, 
         Parent2 target,
         SelectedCompartmentPartType targetPartType, 
         Entry2 targetEntry)
    {
        Parent1ReferencesParent2 result;
        result = new Parent1ReferencesParent2(source, target);
        if(sourcePartType== SelectedCompartmentPartType.Head)
            // use a empty guid for the Head
            result.fromEntry = Guid.Empty; 
        else
            result.fromEntry = sourceEntry.Guid;
    
        if(targetPartType== SelectedCompartmentPartType.Head)
            // use a empty guid for the Head
            result.toEntry = Guid.Empty;
        else
            result.toEntry = targetEntry.Guid;
    
        return result;
    }

  11. In the CreateElementLink() method you have stored the source and target entry information somewhere; my library does not know about this location. So we need two additional methods to compare an entry with a relationship and answer the question "Is this entry the source of a given relationship?" and the same for the target. These code resists in the same file:
    public override bool IsEntryConnectionSource
        (Entry1 entry, 
         Parent1ReferencesParent2 connection)
    {
        if (entry == null)
            return connection.fromEntry.Equals(Guid.Empty);
    
        return connection.fromEntry.Equals(entry.Guid);
    }
    
    public override bool IsEntryConnectionTarget
        (Entry2 entry, 
         Parent1ReferencesParent2 connection)
    {
        if (entry == null)
            return connection.toEntry.Equals(Guid.Empty);
    
        return connection.toEntry.Equals(entry.Guid);
    }

    Always care for entry == null, this will be used to check whether the head of the shape is meant. Even if you do not allow the head to be source or target this method will be called with a null parameter from time to time.

  12. Create a partial class for your Domain Model (CompartmentMappingExampleDomainModel) and add the following methods.
    protected override Type[] GetCustomDomainModelTypes()
    {
      return CompartmentMappingUtil.AllCompartmentMappingRules(this);
    }

    (If you have already some custom rules, you can use an overloaded version of the AllCompartmentMappingRules() method.)

  13. In the DslPackage project create a partial class for the generated Command Set and add the following code:

    protected override IList<MenuCommand> GetMenuCommands()
    {
        return CompartmentMappingUtil.RemoveRerouteCommand
                                    (base.GetMenuCommands());
    }

That’s all. The mapping from compartment entry to compartment entry should be working after compiling the solution.

Advanced Features

As I mention above you can mix compartment and regular shapes. You only need to create a DSL with these shapes and configure the xml file another way. As you see, inside the <Connection> element there is no longer a reference to the diagram elements, only the domain classes are used here. Obviously if you use inheritance all your classes need to have the same base class for <DomainClass> itself and for <EntryDomainClass>. If the concrete class is mapped to a compartment shape, the compartment mappings, otherwise a mapping of regular shapes, will be used.

If one of source or target is always a regular shape, please use ModelElement for <EntryDomainClass>.

At the bottom of the xml file you have to list all shapes that play a role in your mapping. Use the xml elements <CompartmentShape> and <RegularShape> therefore.

Inside your Parent1ReferencesParent2BuilderInstance class you can override some more methods to allow or forbid the creation of connectors. I think the names and signatures speak for themselves:

  • bool CanAcceptAsCompartmentSource
    (SOURCE_ELEMENT candidate,
    SelectedCompartmentPartType partType,
    SOURCE_COMPARTMENT_ENTRY candidateEntry)
  • bool CanAcceptAsCompartmentTarget
    (TARGET_ELEMENT candidate,
    SelectedCompartmentPartType partType,
    TARGET_COMPARTMENT_ENTRY candidateEntry)
  • bool CanAcceptAsCompartmentSourceAndTarget
    (SOURCE_ELEMENT sourceElement,
    SelectedCompartmentPartType sourcePartType,
    SOURCE_COMPARTMENT_ENTRY sourceEntry,
    TARGET_ELEMENT targetElement,
    SelectedCompartmentPartType targetPartType,
    TARGET_COMPARTMENT_ENTRY targetEntry)

Advanced Sample

In addition to the sample above I build a second one. There I want to create mappings form some Inputs to some Outputs, where one of these Inputs or Outputs can be an entry of a compartment shape or a whole regular shape. This regular shape contains a property Kind that makes the shape to an Input or an Output (to show you the use of the CanAcceptAs... methods).

advancedsample

The DSL model looks like this:

advanceddslmodel

The project with all sources is part of the samples in the JaDAL download.

Download

The compartment mapping library and both samples are part of JaDAL – Just another DSL-Tools Addon Library which you can download from CodePlex.

Changing the title of Compartments using code

Tags: , , ,
No Comments »

When using CompartmentShapes in your DSL you can define the text displayed in the head of each compartment in the DSL designer (there is a property Title for every compartment):

compartmentheadertext

Unfortunately I didn’t find any way to change this text from my source code or by binding it to some DomainProperty. I’m using an abstract base class with the embedded fields that are displayed in this compartment and I have some concrete classes inheriting from the base class. The shapes for all those concrete classes should look nearly the same; the only difference is the compartment header text. I think it is not a good idea to model a separate shape for every concrete class only for having different header texts.

model

After a little bit of research I found an extension point to achieve my aim. The CompartmentShape class contains a GetCompartmentDescriptions() method. To override this method you have to create the CompartmentShape as Double Derived and create a partial class.

I think you should take a look at the implementation of this method in the generated class. Indeed this method is defined in the CompartmentShape class, but it caches the value in a static field. So all shapes (within the same type) share the same CompartmentDescription. Now you can change it before returning it in this method. Just alter the text or do some other funny things like coloring or setting font types.

public override CompartmentDescription[] GetCompartmentDescriptions()
{
    CompartmentDescription[] descriptions;
    descriptions = base.GetCompartmentDescriptions();

    // I know there is only one CompartmentDescription
    // but maybe you should check it first
    CompartmentDescription desc = descriptions[0];

    if (this.ModelElement is ClassA)
        desc.Title = "Fields of A";

    if (this.ModelElement is ClassB)
    {
        desc.Title = "Fields of B";
        desc.TitleFontSettings = new FontSettings {Bold=true};
        desc.CompartmentFillColor = Color.LightBlue;
    }

    return descriptions;
}
shapes 

However there is a little drawback: This method is called only once (at least it seems so) when a shape is created (or the diagram is loaded). After that you cannot change the compartment description. For my problem it doesn’t make any difference. Maybe you can call some method to invalidate the shape and force it to reevaluate the method, but I’m not sure. If somebody knows some working solution for this, please leave a comment.

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in