Ticklish Techs

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;
    }
}

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.

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.

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.

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.
    
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).

The DSL model looks like this:

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.

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):

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.

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;
}

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.

Today I released the new version of PhotoTagStudio with a lot of stability and usability enhancements and the ability of changing exif time and date data.

Some more new features are:

• Support for drag and drop from PTS to other applications (e.g. the explorer).
• Navigating from picture to picture in the current folder with the PageDown and PageUp keys.
• Deleting files from within PTS with a Button and the Del key (don’t worry, you will be asked again before deleting and deleting means moving to the recycle bin!)
• Since PTS contains more and more features form version to version some of them are now by default hidden. Take a look at the configuration dialog or use the right-click-context-menu on the tab header on the right side if you are looking for a missing feature.

See http://phototagstudio.irgendwie.net/

One would think, it is a simple feature in the DSL Tools framework to allow and forbid the deletion of model elements, but it isn’t.

There are a few posts in the DSL Forum and it seems there are even a few methods to forbid the deletion. But every single solution has its pros and cons and you have to write a little bit of code yourself. Just take a look at the following postings:

• http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=73606&SiteID=1
• http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=780425&SiteID=1

One solution is to throw an exception from within a DeletingRule, but I personally don’t like this. It means, the user is able to click on a delete menu item and then an error message box pops up. This is not a good user experience!

I think the best would be to hide the "delete" commands from the menus. If you disable the commands, the delete key isn’t working, too. But there are two places where the user can find such a "delete" command for the model elements: on the design surface of the DSL Editor and on the items of the DSL Explorer (and further more: the DSL Explorer has a "delete" and a "delete all" command on different tree nodes). You have to handle both cases.

I would just like to have somewhere a bool CanDelete() method that is called every time the menu is shown and asks my component whether to allow the deletion or not.

Now the good news: I added this Method and wrote a little piece of code for it!

First I created a very simple Interface

public interface IDynamicCanDelete
{
    bool CanDelete();
}

With this interface you can add the missing method to your shapes or model elements. I recommend to implement this method in the model elements since the model explorer knows nothing about your shapes and cannot call this method if implemented in the shape classes. You don’t need to implement this method for every model element, but only for those you want to forbid deletion. Just return false or implement some logic based on the model element state.

If this feature would be part of DSL Tools that is all you need to do. Though since it is only an addition to it, you have to connect some methods with my library:

• In the DslPackage project add a partial class for your MyLanguageCommandSet and override the following method:

protected override void ProcessOnStatusDeleteCommand
                                   (MenuCommand command)
{
    OnStatusDeleteCommandLogic.ForEditor(command, 
                    this.CurrentDocumentSelection, 
                    base.ProcessOnStatusDeleteCommand);
}

• In the same project add a partial class for your MyLanguageExplorer and override two methods:

  protected override void ProcessOnStatusDeleteCommand
                                      (MenuCommand cmd)
  {
      OnStatusDeleteCommandLogic.ForExplorerDelete(cmd, 
                    this.SelectedElement,
                    base.ProcessOnStatusDeleteCommand);
  }
  
  protected override void ProcessOnStatusDeleteAllCommand
                                          (MenuCommand cmd)
  {
      OnStatusDeleteCommandLogic.ForExplorerDeleteAll(cmd, 
                   this.ObjectModelBrowser.SelectedNode, 
                   base.ProcessOnStatusDeleteAllCommand);
  }

That’s all, but what’s happening inside the OnStatusDeleteCommandLogic class? I’m looking for the selected elements (that are shapes in the editor or TreeNodes in the DSL Explorer) and check whether they implement the IDynamicCanDelete interface. If there is this interface I will call the CanDelete() method and if it returns false the delete menu command will be disabled and set to invisible.

For the Editor I will check the shape and the corresponding model element. If there are multiple elements selected only one must report false to disable the command.

The DSL Explorer provides a Delete All command on some nodes. For this command I will check all children but not the grandchildren.

For more details please take a look at the source code.

Update

This code is now part of the JaDAL – Just another DSL-Tools Addon Library project. Please download the current version from that page. The download over at CodePlex contains the source code described here, an example DSL language and the library as a binary. Future enhancements of the code will be published there, too.

Additional bug fix for the explorer

DuncanP mentioned at the end of his article a small bug in the behavior of the model explorer. This bug can make the “Delete All” command visible when you don’t want it to be. He described an idea for a bug fix. I can find the same wrong behavior in the current release for Visual Studio 2008 and implemented a bug fix the way DuncanP pointed out:

Add the following code in the MyLanguageExplorer class

public override void AddCommandHandlers(IMenuCommandService menuCommandService)
{
    base.AddCommandHandlers(menuCommandService);

    MenuCommand deleteAllCommand = 
        menuCommandService.FindCommand
            (CommonModelingCommands.ModelExplorerDeleteAll);
    this.ObjectModelBrowser.AfterSelect += 
        delegate
            {
                ProcessOnStatusDeleteAllCommand(deleteAllCommand);
            };
}

Hi!

I just found a solution to a problem that was getting on my nerves for quite a time: I am using three computers, all WinXP Pro. They are all connected in one simple network and I don’t use much more than some folders to copy files from here to there. It worked fine for a long time but one day I couldn’t connect to anyone of the computers anymore. I am pretty sure I didn’t change a thing – it just happened. I browsed a lot (and I mean a lot) of websites that are dedicated to this problem. Most of them say (text copied from here):

1. Start the registry editor (e.g., regedit.exe).
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \lanmanserver\parameters.
3. Double-click IRPStackSize (or if this registry setting does not exist, create it of type DWORD and ensure the case is correct).
4. Change the base to decimal, set the value to the default value for your OS, and click OK.
5. Reboot the computer or restart the “Server service”.

It did not work for me.

But I found the solution two minutes ago one on single German web site: When changing the value of IRPStackSize DON’T CHANGE TO DECIMAL. Change to (or leave it at) hex!.

Hex 30 (= Dec 48) was enough for me and after a reboot it worked again.

What a bug, MS, please fix it!