Gokhan Altinoren's Blog and Projects

21 Nisan 2008 Pazartesi

Using WPF As The Designer Surface In DSL Tools

Some time ago, Stuart Kent published the roadmap for DSL Tools. The idea of Dsl extensibility and WPF-based design surface mentioned there easily make someone drool. In the comments to the same post, he also mentions a way to provide your own editor instead of the built-in one. Here's my take on using that technique to provide a custom editor-wannabe in WPF.

Create a new Domain-Specific Language Designer (File \ New \ Project \ Other Project Types \ Extensibility)
Name the project as WPFDSLDesigner
Select Class Diagrams template and click Finish to accept the defaults.
On the DSL Explorer tool window, click on the Editor node. Make a note of the FileExtension property in the Properties Window. Right click Editor node and Delete it.
Right click on the WPFDSLDesigner root node and select Add New Custom Editor. Set the FileExtension property. Set Root Class property to ModelRoot.
Transform All Templates using the rightmost button on top of the Solution Explorer.
Try building the project. The compiler error will lead you to the customization point. The cool thing with the DSL Tools is that, it clearly marks customization points expected by the developer with appropriate comments, all the time. We will add a partial class to supply our own getter in this case, as described by the comment in the code.
Add a project reference to WindowsFormsIntegration assembly (The last element in the dialog, most probably)
Add a class named WPFDesignerDocView to the DSLPackage project. (I created a DocView folder to group added files in a single place.) Change the code as follows:

namespace Company.WPFDSLDesigner.DslPackage

{

    using System.Windows.Forms;

    using System.Windows.Forms.Integration;

    internal partial class WPFDSLDesignerDocView

    {

        private ElementHost host;

        public override IWin32Window Window

        {

            get

            {

                if (host == null)

                {

                    host = new ElementHost { Dock = DockStyle.Fill };

                    WPFDesigner designer = new WPFDesigner(this);

                    host.Child = designer;

                }

                return host;

            }

        }

        protected override bool LoadView()

        {

            bool result = base.LoadView();

            if (result)

            {

                ((WPFDesigner)host.Child).DocumentLoaded();

            }

            return result;

        }

    }

}
Add a User Control (WPF) item to the project, name it WPFDesigner. Change the Xaml code of the UserControl as follows:

<UserControl x:Class="Company.WPFDSLDesigner.DslPackage.WPFDesigner"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

<UserControl.Resources>

<Style TargetType="{x:Type ListBox}">

<Setter Property="ItemsPanel">

<Setter.Value>

<ItemsPanelTemplate>

<StackPanel />

</ItemsPanelTemplate>

</Setter.Value>

</Setter>

<Setter Property="ItemTemplate">

<Setter.Value>

<DataTemplate>

<Border BorderBrush="Black" BorderThickness="1" CornerRadius="5" Margin="6">

<Label Content="{Binding Path=Name}"></Label>

</Border>

</DataTemplate>

</Setter.Value>

</Setter>

</Style>

</UserControl.Resources>

<Grid>

<ListBox Name="modelClassViewer" ItemsSource="{Binding Mode=OneWay}" />

</Grid>

</UserControl>
And change the code of the UserControl to:

namespace Company.WPFDSLDesigner.DslPackage

{

    using Microsoft.VisualStudio.Modeling.Shell;

    using System.Collections.Generic;

    public partial class WPFDesigner

    {

        public ModelingDocView DocView { get; set; }

        protected ModelRoot root;

        public WPFDesigner()

        {

            InitializeComponent();

        }

        public WPFDesigner(ModelingDocView docView)

            : this()

        {

            DocView = docView;

        }

        public void DocumentLoaded()

        {

            if (DocView != null && DocView.DocData.RootElement != null)

            {

                // Had some problems binding to ModelRoot.Types directly. Using a custom list instead.

                var list = new List<ModelType>();

                list.AddRange(((ModelRoot)DocView.DocData.RootElement).Types);

                modelClassViewer.DataContext = list;

            }

        }

    }

}
Your final project structure should be looking something like this:
Run the solution to open the Debugging project. Open the Sample.mydslx file. That's all.

And the result is:

Nothing fancy at the moment, but it's pure WPF. Add some compartment shapes and connectors, layout the entities rather than using a StackPanel and you're almost done. Nested shapes and such should be a breeze to implement.

Thank god they're working on this some future version of DSL Tools, WPF is so powerful to customize. I'm expecting that in the final version, we'll optionally be able to provide our own templates instead of the generated ones for customize-like-hell experiences.

Here are some future research points for the implementation above:

We can write a code generator to create shapes based on the Diagram Element properties in DslDefinition.dsl. Compartments, decorators, appearance properties etc. Why enumerate a bunch of types at runtime when we're already generating the rest design time?
Databinding to LinkedElementCollection failed pretty bad, VS kept crashing in every single case. Hey, I want to use built-in collections. Any INotifyCollectionChanged, by the way?
We should be mapping WPF menu items to package menus (VSCT). Add new property, validate etc.
We should either use the original .designer file structure to persist the layout etc. or find a way to store that data somewhere. (Designer file is the best)
Performance is not so great. I tried some 3D and it's even worse, much worse. There's something fishy going-on when you host a WPF control on top of a win32 container, or in VS, or both.

Code Generation | DSL Tools | VSIP | VSX | WPF

posted on 21 Nisan 2008 Pazartesi 14:55:54 UTC

30 Ocak 2007 Salı

On Software Factories and DSL Tools

Last week, Edward Bakker started summarizing some notes and resources on Software Factories, then Jezz Santos added this one on "When would you build one". (Their latest posts have a cyclic dependency, by the way :) I don't know if people (apart from these two guys. They're already into it to their neck :) are more talkative on SF notion lately or my doors of perception are more open to this kind of posts since I'm trying to build one myself, but I started seeing more and more on this subject.

I remember seeing a discussion between Grady (an IBM Fellow, as his blog says) and Greenfield, Cook, Wills and Kent on the UML vs SF kind of debate (and I assure you I didn't have a clue back then how important things they're talking on). Then I interested in code generation. Then I had to use NHibernate for a little project. Then I wanted to generate .hbm.xml documents in VS. Then I thought I prefer attribute decorations rather than XML declarations. Then I found out DSL Tools in this post (Sequence ended in mid 2006. Quite late for me, huh?).

Now, with DSL Tools in hand, I feel like I can take over the world :) Seriously, check the comments for this post. People want tools for their everyday needs. Put some guidance in, integrate with the IDE and they're willing to do the rest. Learning curve might be a little steep but anybody dreaming a tool to generate some code or project instruments or a custom domain intelligent enough to do some repetitive / predefined work may start building it right now or use existing ones, be it DSL Tools, GAT / GAX or one of the available software factories.

DSL Tools | Software Factories

posted on 30 Ocak 2007 Salı 00:23:29 UTC

29 Ocak 2007 Pazartesi

How To: Get correct DTE instance when running .tt file through a custom tool in DSL Tools

It sometimes get frustrating when you debug your project through another instance of Visual Studio, especially if you manipulate the "active" DTE within your debug project. I somehow ended up to the following when getting a reference to DTE:

System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.8.0");

It worked most of the time, but "not all the time" means you may add a project to the solution where your code resides (the parent VS instance), rather than where the debugging session is. So, after some research, DTE code turned into this:

[DllImport("ole32.dll")]

public static extern int GetRunningObjectTable(int reserved, out IRunningObjectTable prot);

[DllImport("ole32.dll")]

public static extern int CreateBindCtx(int reserved, out IBindCtx ppbc);

[CLSCompliant(false)]

public static DTE GetDTE(string processID)

{

IRunningObjectTable prot;

IEnumMoniker pMonkEnum;

string progID = "!VisualStudio.DTE.8.0:" + processID;

GetRunningObjectTable(0, out prot);

prot.EnumRunning(out pMonkEnum);

pMonkEnum.Reset();

IntPtr fetched = IntPtr.Zero;

IMoniker[] pmon = new IMoniker[1];

while (pMonkEnum.Next(1, pmon, fetched) == 0)

{

IBindCtx pCtx;

CreateBindCtx(0, out pCtx);

string str;

pmon[0].GetDisplayName(pCtx, null, out str);

if (str == progID)

{

object objReturnObject;

prot.GetObject(pmon[0], out objReturnObject);

DTE ide = (DTE)objReturnObject;

return ide;

}

return null;

}

Code Generation | DSL Tools | Visual Studio

posted on 29 Ocak 2007 Pazartesi 22:17:43 UTC

How To: Create additional registry keys with DSL Tools Setup Projects

I was trying to solve the Custom Tool property issue with .actiw files in ActiveWriter, as suggested by Bogdan Pietroiu months ago, and spent a clear hour trying to figure how to inject my own registry keys into WiX setup project of DSL Tools. I modified the .vstemplate for .actiw files to include the following:

...

</CustomParameters>

...

and thought that the file, when added to the project, will have Custom Tool property already set. I was appearently wrong (documentation says it should work).

Bogdan's suggestion was to have a key named after the file extension under Generators\{Language}, and I manually confirmed that it works great. So, how to automate the process of adding this reg key through the setup? WiX Toolkit documentation shows the way, so I copied Registry.wxs to have my own key registered.

<?xml version="1.0" encoding="utf-8"?>

</FeatureRef>

</Component>

</DirectoryRef>

</Fragment>

</Wix>

<Registry> elements define the key to be added, as you may have guessed. Anyway, although I changed the build action on the .wxs and although it seems that Candle and Light picked up the file, the installer didn't add the registry key. So? Orca to the rescue. You should check Component and Registry tables in .msi file to check if your key slipped in, and Orca shows them quite detailed. In my case, though, it shows the absence of my additions.

Long story (not so) short, it seems that I should examine Registry.tt as the first step, but didn't. To include your ComponentRef in DefaultFeature, you should have your Fragment as FragmentRef in Main.wxs . So, you should add each of your custom fragment in the list defined in customFragmentIds in InstallerDefinitions.dslsetup as shown below:

<installerDefinition xmlns="http://schemas.microsoft.com/VisualStudio/2005/DslTools/InstallerDefinitionModel"

...

customFragmentIds="CustomToolFragment">

I hope this info helps someone.

ActiveWriter | WiX | Setup | DSL Tools

posted on 29 Ocak 2007 Pazartesi 21:13:31 UTC