.NET & Funky Fresh : databinding, NHProf

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.

Porting NHProf from WPF to Silverlight – Day 1

Rob Eisenberg — Thu, 25 Mar 2010 20:33:00 GMT

This is a true story. It’s a story about porting a non-trivial WPF application, NHProf, to Silverlight 4. The story begins today with my first actual work on the porting process. Microsoft has been preaching how easy it is to move between these platforms. Are they telling the truth? I’ll (try to) let you be the judge. I’ve been a bit lax in my blogging lately, but I’m going to try and give a semi-regular account of my progress on this port along with the challenges I meet along the way. Perhaps I’ll be able to offer some meaningful workarounds that others can use; perhaps not. Maybe, dear reader, you can recommend some solutions to me.

Today I spent about 6 hours on the Silverlight version of NHProf. I basically did a File->New Project and began moving small pieces of the application shell over to Silverlight. The new application is not much to see at this point…most of the UI is missing entirely.

Below is a summary of the platform inconsistencies I came across in the first six hours of work:

Xmlns – Silverlight 4 allows assemblies to define custom Uri-based Xml namespaces. Unfortunately, Microsoft has done a rather poor job of using this feature themselves. The first issue I came up against today was related to this. It’s not a big problem, but rather an annoyance. The reason is that some controls are in different assmelbies/namespaces in Silverlight than in WPF. Take DockPanel, for example. It’s a core Panel in WPF, but not in Silverlight. Microsoft hasn’t patched up the namespaces for this, so if you port code using DockPanel, you have to go add custom xmlns everythwere. Yuck. This is true of everything in the Silverlight Toolkit. It would be really nice if they took everything in the SDK and everything in the Toolkit and just put them in the default namespace. Unfortunately, this one issue is probably going to prevent a direct reuse of any of our views.
TabControl – If you have seen the NHProf UI, It’s fairly obvious that we rely heavily on the TabControl. Unfortunately, the Silverlight TabControl is completely broken for data binding. Furthermore, it doesn’t have all the necessary template properties either. Basically, it’s completely different from the WPF version and completely unusable if you are using an MVVM architecture. My work around has been to use a horizontal ListBox for the “tabs” and a ContentControl for the “SelectedItem,” then rely on styling to make it look like a tab control. You can see this in the screenshot above (minus the styling of coarse).
ToolTip vs. ToolTipService – In WPF, every control has a ToolTip property; not so in Silverlight. You have to use an attached property called ToolTipService.ToolTip instead. Again, not a big problem, but it forces me to change every view.
Grid.IsSharedSizeScope and ColumnDefinition.SharedSizeGroup – Missing. There’s no way I know of to do a shared size scope layout in Silverlight. We used this quite a bit in the WPF version. Most of our “data grids” are actually list boxes with shared size scope layout. It was just simpler and more light weight. To solve this, I’m actually using the Sivlerlight DataGrid control. You can see it in the screen shot above displaying the Session Statistics. Ultimately, I think this will be an improvement to the UI. It just seams a bit heavy-weight considering that all of our grids are readonly. Suggestions?
ItemsControl.AlternationCount – Missing. This was primarily used in the style to generate alternating row colors. Since most of our ItemsControls/ListBoxes are going to be switched to DataGrid, this probably won’t be a big deal in the end. Still, I’d be interested in knowing what the proper way to do alternating row styles in Silverlight is.
TextTrimming="CharacterEllipsis" – Missing. We just have to go with WordEllipsis or roll our own ;(
DynamicResource – Missing. I’ve temporarily removed all the styles for the views I have ported. I’m really not sure what the ramifications of the missing DynamicResource will be in the end.
HeaderedContentControl Template uses a StackPanel – The HeaderedItemsControl’s template is built wrong…Period. It uses a StackPanel for layout and that prevents styling the control to expand properly. It should use a DockPanel. As I mentioned above, DockPanel is not in the core, which is probably why the HeaderedItemsControl is broken. Now, if they would just move the DockPanel….
ContextMenu – Missing. Silverlight offers mouse right-click support, but no ContextMenu out of the box. We are going to have to build this one from scratch.
DispatcherTimer(DispatcherPriority.Normal) – There’s no notion of DispatcherPriority in silverlight! So usage of the Dispatcher and DispatcherTimer can be quite different. Unfortunately, I won’t know the full effect of this until we start pushing lots of data through this thing…I don’t think it will be a problem. But, when it comes to SL vs. WPF, I’ve learned not to take anything for granted.
RegexOptions.Compiled – Missing. We’ll just have to do without that.
String.StartsWith - Missing overload for culture. Created an extension method as workaround.
StringBuilder - Missing overload to insert a character. Created an extension method as workaround.
DateTimeFormatInfo - Missing GetAllDateTimePatterns. Created an extension method as workaround. Faked the implementation…

Hmm. That’s a bit disconcerting for a mere six hours in. What’s interesting to note are the the differences in core APIs. I expected the graphics stack to have some inconsistencies, but I didn’t expect to hit BCL differences so quickly. I also expected to get a lot more of the shell done today. Looking at the screenshot above….I’m a bit embarrassed at the lack of progress. So far, porting WPF to Silverlight is slow going.

NHProf and Caliburn Testability

Rob Eisenberg — Fri, 30 Oct 2009 19:07:00 GMT

I’ve heard some developers asking about UI testing lately. Specifically, there have been some questions about what we did with NHProf. So, I thought I would write a little bit about that here.

There are a variety of different types of tests you can do. In my experience some have a better ROI than others. For example, we don’t do any UI testing with automation APIs. Those are pretty painful, brittle tests to write and we haven’t worked in scenarios where they would really help us. The two main types of UI testing we tend to do are Unit Tests of the View Model and Binding Validation Tests against the Views.

View Model Tests

There are many advantages in taking a View Model approach to building your UI. When we build VMs we try and push as much of the UI state into our models as possible. By doing this we “virtualize” our entire UI, allowing us to simulate a large percentage of the UI behavior without ever opening a Window or showing anything on screen. This is great for testability. It means, we can use simple state based unit tests to verify the behavior of our UI. Here’s a simple example from NHProf:

public class StatementFilterTestFixture
{
    private readonly FilterServiceModel service;
    private readonly IList<IStatementSnapshot> statements;

    public StatementFilterTestFixture()
    {
        statements = new List<IStatementSnapshot>
                         {
                             create_a_statement(100, "hello"),
                             create_a_statement(200, "select * from something"),
                             create_a_statement(300, "select field1 from something"),
                             create_a_statement(400, "select monkey,ninja,pirate,robot from floating_island"),
                             create_a_statement(500, ""),
                         };

        service = new FilterServiceModel();
    }

    [Fact]
    public void Can_filter_by_both_duration_for_values_less_than_300_and_contains_text()
    {
        var filters = new ObservableCollection<IFilter>
                          {
                              new FilterByDuration
                              {
                                  Operator = ExpressionType.LessThan, 
                                Value = "300"
                              },
                              new FilterBySqlContains {Text = "something"}
                          };

        service.Filters = filters;

        Assert.Equal(1, statements.Where(x => service.FilterStatement(x)).Count());
    }
}

Binding Validation Tests

While the WPF/SL data binding mechanism opens the door to building rich View Models, it also introduces a new problem: potential binding expression errors. Because we didn’t want to give up the productivity benefits of databinding and View Models, we chose to take some time to build a binding validation framework. We then write simple tests to insure that there are no typos or silly mistakes in our binding expressions. Here’s an example test from NHProf:

public class StatisticsDetailsTestFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<StatisticsModel> bindings;

    public StatisticsDetailsTestFixture()
    {
        bindings = Validator.For<StatisticDetailsView, StatisticsModel>()
            .Validate();
    }

    [Fact]
    public void BindingsDoNotHaveErrors()
    {
        Assert.False(bindings.HasErrors, bindings.ErrorSummary);
    }

    [Fact]
    public void NameIsBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.DisplayName));
    }

    [Fact]
    public void StatisticsAreBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.SortedStatistics));
    }
}

You can actually take this one step farther as José Romaniello has in testing his Chinook Media Manager. Take a look at this sweet piece of code.