Friday I only had a few hours to work on the port. I thought I might look into what it would take to add the main menu. It’s an important part of the shell that I completely skipped in my first pass. Unfortunately, there aren’t really any free or open source menu controls that I could find which fit the bill exactly. I wanted to use VectorLight’s Menu, but I couldn’t get it to work in SL4. So, I ended up using the free DevExpress menu control. Unfortunately, I’m probably going to have to rip that out eventually because it doesn’t support shortcut keys. Neither of these controls support SL4’s ICommand interface. Thankfully, Caliburn has a better way to handle commands, so that didn’t set me back. When VectorLight’s control is fixed, I’ll probably end up switching to that, but I wanted to get something up and running in the mean time. I also started porting a few other parts of the shell, such as the header and chrome. This brought me to the second major shortcoming in Silverlight: No DynamicResource. I spent a good deal of time trying to figure out a workaround for that. I came up with something that I think will work for our purposes, but definitely isn’t generalizable. Lack of this functionality is a real problem in Silverlight. Below is a screen shot of the shell after day two. It’s not pretty and won’t be for a while, but I wanted to include it for historical purposes. After that you will find a list of a few other compatibility issues I encountered while working on the above two areas.
Issues from Day 2
- The Control.MouseDoubleClick event is missing. Eventually, I will have to implement it manually, probably with an attached property.
- TextBlock.Foreground and TextBlock.FontFamily are missing. It’s quite convenient to use these attached properties in WPF, but they simply don’t exist in Silverlight. Their absence causes a good deal of additional markup and sometimes “hacks” to get certain controls in certain parts of the visual tree to look right.
- No *Connection, *Reader, etc. This is pretty obvious. But, I wanted to include it for completeness. I didn’t expect to deal with this, but it turns out the profiler’s front and backend are not as isolated as I thought they were. We’ll have to do some re-architecture in order to fix this.
- There is no MainMenu control as I mentioned above. Currently, there’s a lack of good free or open source options for SL4. I’m expecting this to be improved upon shortly. Regardless, none of the controls available have an API that is compatible with WPF (especially if you used databinding or commands with your menu). So, if you are porting anything with menus, you are going to have to redo the whole thing.
- Drawing Brush is missing. For that matter, drawings are missing…I’m not sure what we will replace this with just yet. Fortunately, it’s only used in one place in our application.
- x:Array is missing. We originally uses this to store the alternating background color array for all our grids as a resource. But, since ItemControl doesn’t support that in Silverlight, we won’t be using this in the end.
- No DynamicResource support, as mentioned above. For the profiler we have to load different color schemes based on which version you are using. I ended up creating an attached property to place on resource dictionaries, which allowed me to merge the dynamic color scheme in at the appropriate time during initialization. It seams to work so far. But, it’s not a generalizable solution, because you can’t change the “dynamic resources” on the fly. My solution only helps solve the issue of resource discoverability in complex scenarios, which is a common use for DynamicResource in WPF.
03-29-2010 5:04 PM
Filed under: .NET 3.0, Xaml, databinding, WPF/e, .NET 3.5, Caliburn, Featured, Silverlight, NHibernate, RIA, MVVM, UI Architecture, NHProf