.NET & Funky Fresh : databinding, NHProf, RIA

Porting NHProf from WPF to Silverlight – Day 7

Rob Eisenberg — Wed, 07 Apr 2010 02:21:00 GMT

Today I worked on statements. They flow pretty naturally out of the sessions functionality. I still have a lot of work ahead of me, so fortunately I only found two new issues today. I was able to rework Xaml in both cases fairly easily.

Binding in it’s Element form is not allowed. Fortunately, I was able to rework it as a markup extension.
ContentControl.ContentStringFormat is missing. I was able to use the StringFormat built into the BindingExtension instead.

Screenshot is below. Aside from the hideous styles…it’s actually starting to resemble itself.

Porting NHProf from WPF to Silverlight – Day 6

Rob Eisenberg — Mon, 05 Apr 2010 21:44:00 GMT

I started working on the most complicated part of the UI: Sessions. There are a lot of different view models and views related to this part. Fortunately, by now, I think I have found most of the issues. But I’m still encountering a few new issues here on day six. Below is the customary screenshot and issue list.

Styles don’t have Resources. We are probably going to have to re-write all of our styles and control template. So, our new solution will take this into account.
ControlTemplate cannot have triggers. See above.
ControlTemplate cannot have resources. See above.
Uri is missing PathAndQuery – I implemented this manually by combinding AbsoluteUri and QueryString with a ‘?’ in between.
MultiBinding is missing. We are going to do some major rework on that view unfortunately. I’ll try and provide more details later. Skipped it for now…
No ReaderWriterLockSlim. This was surprising. I really wasn’t sure what to do, so I used a standard lock for now.

Porting NHProf from WPF to Silverlight – Day 5

Rob Eisenberg — Fri, 02 Apr 2010 16:31:00 GMT

Well, I’m pleased to say that on Wednesday I only encountered one new* issue during the port. ListBox does not support grouping. One neat thing in WPF is that all the items controls supported grouping. One of the reports we had was a set of master/details grids where the master was a grouped ListBox. Needless to say, this entire report had to be redesigned to work around this issue. Truth be told, I never really liked the way that report was set up. As a solution I decided to use the Silverlight DataGrid with two levels of grouping. That issue aside, it was pretty quick work to port all the reports. As part of the process, I made the reports mechanism a little easier to maintain. Basically, anything that implements IReport will appear in the report list, will be added to the reports menu and will automatically have its view bound appropriately. Yay for IoC and Caliburn! Here’s a screenshot:

*Just as a reminder: When I say “new” issues I don’t want to insinuate that it is the “only” issue I encountered while working. I have encountered dozens of issues every day. But I am only recording here issues that I find that I haven’t previously encountered on this project. Trying to track every “instance” of an issue would be unmanageable.

Porting NHProf from WPF to Silverlight – Day 4

Rob Eisenberg — Thu, 01 Apr 2010 18:36:00 GMT

On Tuesday I spent a decent amount of time fleshing out the last remaining features under the Options menu. I then did some general reorganization to the project structure. Along with the port to Silverlight, I’ve been upgrading the application to use Caliburn 2.0 which is working out exceedingly well :) In fact, some of Caliburn’s features are making it very easy to work around the differences between the WPF and Silverlight platforms. After the reorganization, I decided I would start porting over the reports. As has been my pattern, below is a screenshot and the list of *new* issues I encountered. I’m really glad there weren’t as many as on Monday…

UpdateSourceTrigger=PropertyChanged is missing. There are workarounds which wire for events and manually update the bindings. I used Caliurn 2.0’s C over C binding to do this automatically :)
RelativeSource FindAncestor is missing. Fortunately, I replaced our homegrown grid with the Silverlight DataGrid and was able to eliminate the need for this in this scenario.
Hyperlink.Tag is is missing. Strange isn’t it. I reworked the code to use a HyperlinkButton.
Binding.StringFormat syntax is different. In WPF, you escape like this Text="{Binding AverageStatementsPerSession, StringFormat={}{0:0.#},FallbackValue=0}" but that causes a compile-time error in Silverlight. What is worse is that it doesn’t tell you where. It just complains that there is something wrong with a markup extensions somewhere in your Xaml. I fixed it with the following change Text="{Binding AverageStatementsPerSession, StringFormat=\{0:0.#\},FallbackValue=0}"
GridSplitter is missing ResizeBehavior and ResizeDirection. Fortunately, it seams to work pretty well without them. I have a couple of issues with this that I still need to look into though.

Porting NHProf from WPF to Silverlight - Day 3

Rob Eisenberg — Wed, 31 Mar 2010 13:58:00 GMT

On Monday I spent a good four hours working on the port. I decided to flesh out the functionality of the Main Menu. As I mentioned before, none of the menu controls available support commanding. Fortunately, Caliburn has its own mechanism which is much richer than what you get out of the box anyways. So, I began hooking this up, fleshing out the appropriate commands and implementing the various features of the application related to them. This approach actually brought me in touch with a very wide range of the application’s features. As a result, I ended up hitting a lot of issues. I calculated, that on average, I was hitting a *new* API issue (one I hadn’t seen previously on this project) every ten minutes for the entire four hour period. That was frustrating to say the least. Below is a (hideous) screenshot and a list of the issues I hit.

Style.Triggers are not supported. Ultimately this means we are going to have to refactor a lot of styles. Temporary fix to get things running was to comment out the triggers ;(
DataTrigger not supported either. We’ll probably end up refactoring to VSM. Unfortunately, many of our DataTriggers are in Styles…Fixing this is going to be interesting.
Custom Markup Extensions are still not supported in SL4, even after they completely re-wrote their Xaml parser from the ground up to support greater extensibility. My particular scenario was easy to work around by creating a custom IValueConverter. Another reasonable solution might be to create custom attached properties.
Lack of Command Support on Menu controls – This is not a problem with SL4 (except that it doesn’t have any menu controls), but is an issue with the current 3rd party controls. As I mentioned above, Caliburn made this easy enough to work around.
OpenFileDialog is missing CheckFileExists, Title, FileName and RestoreDirectory – We can work around all of this. The major consequence is that the user’s experience with the OpenFileDialog will be degraded.
Missing Timeline.DesiredFrameRate – Apparently you can’t control animation frame rate in Silverlight. I don’t think this will be a major issue.
The following simple storyboard scenario does not work. There’s seams to be a problem setting Storyboards with StaticResource. I used a bit of code-behind to start the animation. There’s probably a better way. Anyone have an idea?

SaveFileDialog missing Title and FileName – Again, this can be worked around. Mostly it involves a degraded user experience.
Process.Start is missing – There was talk of getting something like this into SL4. It would have been nice. We need it to open default apps for certain file types on the OS. We’ll either do without this or push it to our backend (which is not Silverlight).
Enum.GetValues is missing! I found this nice workaround: http://www.dolittle.com/blogs/einar/archive/2008/01/13/missing-enum-getvalues-when-doing-silverlight-for-instance.aspx
File.WriteAllText is internal. It would have been nice to have this, but we can work around it using Streams, etc.
Missing SystemParameters.PrimaryScreenHeight and SystemParameters.PrimaryScreenWidth. We’ll just have to do without…
Missing Serializable and BinaryFormatter. This is a real pain. Many people have asked for this since SL2, but the SL team hasn’t shown any interest in providing this. We are going to have re-write our user settings mechanism.
Missing Button.IsDefault and Button.IsCancel. This can be worked around. It means adding custom keyboard wire-ups for modal dialogs. Yuck.
No Label control – Now that we have ElementName binding why don’t we have a decent label control with Target and ActivatorKey? In the mean time I am using a TextBox. We’ll probably have to fix this with a custom control.
Bindings on DPs don’t default to TwoWay where appropriate. This is mostly an annoyance.
No ValueConversionAttribute to decorate value converters with. Not a big issue. But you need to remove it before you can compile.
Missing Visibility.Hidden. Again, not a big issue. But, you will need to rework code that uses this to use Opacity and IsHitTestVisible.
Missing DependencyPropertyKey. – We had a custom control that required this. We will have to re-write this control.
Missing FrameworkPropertyMetadata. – Same as above.
DependencyProperty is missing OverrideMetadata – Same as above.
TextBox is missing MinLines and MaxLines – We’ll manage without this by hardcoding height in pixels (yuck!)

Porting NHProf from WPF to Silverlight - Day 2

Rob Eisenberg — Mon, 29 Mar 2010 21:04:00 GMT

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.