Category Archives: DSLs

Posted: Industry Vertical Episode 001

I am proud to present the first episode of Industry Vertical the twice monthly net cast about industrializing software development with Software Factories, Guidance Automation and Domain Specific Languages at This episode starts out with the basics of Software Factories and trys to answer the question “What is a Software Factory”.

Industry Vertical Pre-Production Begins

I’ve decided to try my hand at webcasting. I’m in the stages of preparing a webcast series around using software factories, guidance automation and domain-specific languages called Industry Vertical. I’m planning on taking it slow starting out by providing some introductory material around what software factories are, their benefits and their life-cycle. Then I’ll take everyone step by step building out a software factory from the ground up. I’m hoping this will help everyone out there get started in industrializing software development.


So far, I’ve spent the last month getting my scripts together, creating graphics, setting up a new web site, purchasing audio equipment and I just found a great deal on a Sony HVR-A1 High Definition Camcorder, so once it arrives I’ll be ready to get down to business and start recording the first episode.


Hopefully, my busy work schedule will stay out of the way long enough to keep releases to a regular interval, but we’ll just have to wait and see what happens.


Don't call store.Dispose() if you didn't create it!

So, I’m happily plugging along, adding the ability to import a WSDL file into one of the DSLs for a new Software Factory we’re building at work. And after reading and re-reading the documentation and the DSL Book, I decide I need to call store.Dispose() in my code because I’m finished adding ModelElements to the model and I am leaving the command handler. You know, be neat and tidy when you exit a function dispose of any COM+ interfaces you’ve might have AddRef’d, etc.


So now I’m running the DSL and everything is working like it did before my single line of code, but now after adding the ModelElements to the model POOF! my model explodes! and I’ve lost everything in the model. I try it again a couple more times, kinda like pushing the car back up the hills to see if the brakes will fail for a second time after they did the first, you know typical programmer mentality and sure enough POOF! POOF! POOF! it keeps doing the same thing over and over.


So I trace through the code and notice that after I execute the store.Dispose() and exit the function, I get rerouted to the DocData class and it is trying to save the file and throws an Exception because the diagrams no longer exist.


So I go back and review my code and notice that I am not creating a new store and loading in the model, but I’m using the existing store that is opened by the DSL Editor and when I call store.Dispose(), I’m pulling the rug out from underneath me, the editor and Visual Studio as well.


So, I removed the single line of code that caused me an hour’s worth of grief and everything is working just hunky dory.


I guess it will always be engrained in my head, that unless I’m actually creating the store, I shouldn’t be disposing of it ,otherwise I’ll cause terrible things to happen.


Hopefully this will keep the rest of you from making the same mistake I did.



How to Create a Custom Editor for a Domain Model Element Property

Sometimes when defining a property for a domain model element you may need to use a complex type that has more than one property or can’t easily be displayed using a single text field or drop down in the property editor. A good example might be a class that holds a list of strings for a GUI interface or a Rich Text editor for a custom text field required by your framework.


To resolve this you can create a custom editor and hook it into your domain model that will provide a proper user interface to specify information for your property.


There are three steps you need to take in order to wire your domain property to display a custom editor:


1. Create a class derived from System.Drawing.Design.UITypeEditor that will launch the custom dialog box as below:


   2: using System;
   3: using System.Collections.Generic;
   4: using System.Text;
   6: // Need to add a reference to System.Drawing DLL.
   7: using System.Drawing.Design;
   8: using System.Security.Permissions;
   9: using Microsoft.VisualStudio.Modeling;
  10: using Microsoft.VisualStudio.Modeling.Design;
  12: namespace XXX.UIProcessDesigner.UIEditors
  13: {
  15:     // FxCop rule: must have same security demands as parent class
  16:     [PermissionSet(SecurityAction.LinkDemand, Name = "FullTrust"),
  17:         PermissionSet(SecurityAction.InheritanceDemand, Name = "FullTrust")]
  18:     public class FormPromptUITypeEditor : System.Drawing.Design.UITypeEditor
  19:     {
  21:         /// <summary>
  22:         /// Overridden to specify that our editor is a modal form
  23:         /// </summary>
  24:         /// <param name="context"></param>
  25:         /// <returns></returns>
  26:         public override UITypeEditorEditStyle GetEditStyle(System.ComponentModel.ITypeDescriptorContext context)
  27:         {
  28:             return UITypeEditorEditStyle.Modal;
  29:         }
  32:         /// <summary>
  33:         /// Called by VS whenever the user clicks on the ellipsis in the 
  34:         /// properties window for a property to which this editor is linked.
  35:         /// </summary>
  36:         /// <param name="context"></param>
  37:         /// <param name="provider"></param>
  38:         /// <param name="value"></param>
  39:         /// <returns></returns>
  40:         public override object EditValue(
  41:             System.ComponentModel.ITypeDescriptorContext context,
  42:             IServiceProvider provider,
  43:             object value)
  44:         {
  46:             // Get a reference to the underlying property element
  47:             ElementPropertyDescriptor descriptor = context.PropertyDescriptor as ElementPropertyDescriptor;
  48:             ModelElement underlyingModelElent = descriptor.ModelElement;
  50:             // context.Instance also returns a model element, but this will either
  51:             // be the shape representing the underlying element (if you selected
  52:             // the element via the design surface), or the underlying element 
  53:             // itself (if you selected the element via the model explorer)
  54:             ModelElement element = context.Instance as ModelElement;
  56:             FormPromptUITypeEditorForm theForm = new FormPromptUITypeEditorForm();
  58:             theForm.Value = (string)value;
  60:             if (theForm.ShowDialog() == System.Windows.Forms.DialogResult.OK)
  61:             {
  62:                 value = theForm.Value;
  63:             }
  65:             return value;
  66:         }
  68:     }
  70: }


2. Create a Windows Form dialog that will be displayed when the editor is invoked, such as the one below:




3. Set the Custom Attributes for the Domain Property to reference the UITypeEditor class you have created.


The text is as follows: [System.ComponentModel.Editor(typeof(XXX.UIProcessDesigner.UIEditors.FormActionTypeUITypeEditor),typeof(System.Drawing.Design.UITypeEditor))]


The bold faced text is the full namespace of your class that derives from UITypeEditor.




I normally store all code that I add to a DSL Designer in various folders such as; CustomCode, UIEditors, Validators, etc. That way it is easy to find when I am trying to reference it.


Also, you can debug the UITypeEditor and Dialog by setting breakpoints in the code before you start debugging.