Customizing a DSL needs different expertise based on the amount of customization that you want to apply.
A 'basic' concept that you need to understand is the double derived pattern.
The DSL engine generates classes based on the dsl definition. Those classes are partial class so, like in asp.net or winform, you can create your code for the same class in another file separating it from the automatically generated.
Those classes are split in two separate files, but is essentially the same class so you can't replace a method automatically generated.
To address this problem the DSL framework introduce the double derived pattern. For each class (with the "Generates Double Derived" attribute set) the generated code is set on the base class so you are free to override the automatically generated code in the derived class.
If you have a class named ExampleElement (the one automatically generated if you create a new MinimalLanguage project) and you mark it with "Generates Double Derived" you'll get the following class structure
The framework generates an ExampleElementBase class that contains all the generated code, in the derived class (ExampleElement) you are free to override everything (except the constructor see below).
In case of the Sources property you'll write
public partial class ExampleElement
{
public override Microsoft.VisualStudio.Modeling.LinkedElementCollection<ExampleElement> Sources
{
get
{
return base.Sources;
}
}
}
The case of constructor it's a little bit different....the problem is that DSL tools must generate the constructor for the derived class (if not the framework couldn't instantiate the class). So if you need to override also the constructor you can set the "Has custom constructor".
(Remember to select "Transform all templates" and rebuild!)
In this case a compilation error is generated stating that you have to implement the constructor. Something like
Error 1 "...ExampleElement' does not contain a constructor that takes '0' arguments