Thursday, July 29, 2010

XAML Geometry Path Markup Syntax Summary

WPF/Silverlight has quite a nice syntax for defining paths in XAML.  The documentation explaining the syntax is quite verbose, which is a good thing, but i wrote this post to provide an at-a-glance summary of the various components:

Letter

Description

Syntax

Example

M

Move M startPoint M 0,0

L

Line L endPoint L 20,30

H

Horizontal line H x-coordinate H 90

V

Vertical line V y-coordinate V 90

C

Cubic Bezier curve C controlPoint1 controlPoint2 endPoint C 1,2 2,4 3,2

Q

Quadratic Bezier curve Q controlPoint endPoint Q 1,2 3,2

S

Smooth cubic Bezier curve S controlPoint2 endPoint S 1,2 3,2

T

Smooth quadratic Bezier curve T controlPoint endPoint T 1,2 3,2

A

Elliptical arc A size rotationAngle isLargeArcFlag sweepDirectionFlag endPoint A 2 40 1 1 2,2

Z

Close the current figure Z Z

Notes

  • When sequentially entering more than one command of the same type, you can omit the duplicate command entry, eg - L 100,200 300,400 is equivalent to L 100,200 L 300,400
  • An uppercase command letter denotes absolute values
  • A lowercase command letter denotes relative values: the control points for that segment are relative to the end point of the preceding example
  • Instead of a standard numerical, you can also use the following special values: Infinity, –Infinity, NaN
  • You may also use scientific notation, eg - +1.e17

Tuesday, July 20, 2010

Differentiating MEF Metadata Using Custom Attributes

Discovered something interesting about MEF today when resolving exports and their associated metadata using custom attributes.  Lets say you have two different types of metadata you want to strongly type by using 2 custom attributes and associated metadata interfaces like so:

   1: public interface ILibrarySectionMetadata



   2: {



   3:     string Title



   4:     {



   5:         get;



   6:     }



   7: }



   8:  



   9: public interface ILiveViewMetadata



  10: {



  11:     string Title



  12:     {



  13:         get;



  14:     }



  15: }



  16:  



  17: [MetadataAttribute]



  18: [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]



  19: public class LibrarySectionAttribute : ExportAttribute, ILibrarySectionMetadata



  20: {



  21:     public LibrarySectionAttribute(string title) : base(typeof(UserControl))



  22:     {



  23:         this.Title = title;



  24:     }



  25:  



  26:     public string Title



  27:     {



  28:         get;



  29:         private set;



  30:     }



  31: }



  32:  



  33: [MetadataAttribute]



  34: [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]



  35: public class LiveViewAttribute : ExportAttribute, ILiveViewMetadata



  36: {



  37:     public LiveViewAttribute(string title) : base(typeof(UserControl))



  38:     {



  39:         this.Title = title;



  40:     }



  41:  



  42:     public string Title



  43:     {



  44:         get;



  45:         private set;



  46:     }



  47: }




In other words, the two sets of metadata expose the same sets of properties, but are differentiated by their strongly typed class representations.  Now i expected that this meant i would be able to differentiate the two by requesting (importing) metadata of a certain type, for example the following would only retrieve library sections (ie UserControls decorated with the [LibrarySection] attribute):





   1: [ImportMany]



   2: public List<Lazy<UserControl, ILibrarySectionMetadata>> Sections



   3: {



   4:     get;



   5:     set;



   6: }


It turns out however, that MEF is still using reflection behind the scenes to resolve the metadata, because it will resolve ANY UserControl that is decorated with either attribute, as both have the necessary properties allowing them to be mapped to either metadata type.  This means that you need to differentiate the UserControls with a string identifier in both the attribute and the [Import] declaration to allow them to be differentiated when importing, like so:




   1: [MetadataAttribute]



   2: [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]



   3: public class LibrarySectionAttribute : ExportAttribute, ILibrarySectionMetadata



   4: {



   5:     public LibrarySectionAttribute(string title) : base("LibrarySection", typeof(UserControl))



   6:     {



   7:         this.Title = title;



   8:     }



   9:  



  10:     public string Title



  11:     {



  12:         get;



  13:         private set;



  14:     }



  15: }



  16:  



  17: [ImportMany("LibrarySection")]



  18: public ObservableCollection<Lazy<UserControl, ILibrarySectionMetadata>> Sections



  19: {



  20:     get;



  21:     private set;



  22: }


This is unfortunate (if not a minor problem) because it dirties the consumption class with a magic string, but i dont see another way of achieving the same result when the exported types use contracts that match (in this example, all items exported as UserControls).  This of course also holds true if you are trying to import types with metadata that is a subset of another metadata interface.  For example if live views also had a Description property, then importing library sections would still match with live view UserControls because they provide the Title property necessary for MEF to resolve the library section metadata.

Wednesday, July 14, 2010

Entity Framework CTP 4 Walkthrough

CTP 4 of the entity framework enhancements were released yesterday for review.  I have just started looking at the entity framework as a potential ORM solution for my latest project Worship.  I need an offline database and after looking at MS SQL CE and SQL Lite have opted for SQL Lite due to its smaller assembly size and larger feature set.  One problem i found with the original entity framework is that the designer did not support inheritance very well.  EF itself does support all 3 types of inheritance, but i found the designer lacking and had to resort to editing the XML manually to implement TPT inheritance which is what i wanted to use.  The new CTP of the entity framework has much better support for code driven development of the database model and much simplified use, so im pretty excited about trying it out and will write more on my experiences.  For now, read this post to get a nice overview of the improvements and how they can be used.