Awkward Coder

This is the final post in this mini series, I'm going to show the finished UI user control and how simple it is to host inside a WPF app. The code is available on gitHub  and the published binaries are available via nuGet  (supports .Net version 4.0+). Before I show the finished UI, lets look at the F# Interactive in Visual Studio, this loads, queries & displays the results from an external assembly: What does this look like in my implementation? It's looks pretty familiar right? :) The major difference is I've output the working folder for the F# interactive process when the process starts: I've made this configurable in code, so I thought it would be a good idea to tell the end user where they could put any assemblies they want to reference. How can the user access the working folder? Simply, a right click menu: All the menu options should be obvious, the working folder for the above example is shown below, you can see it has the assembly re...

In this post I'm going to talk about the WPF user control I'm going to use to display the output from the F# Interactive executable, the previous posts ( here & here ) talked about manipulating the standard input & output streams of the executable to provide the following interface: Loading gist .... The control will render any values generated by the Output property on the interface, the property is an Rx stream which generates a new value when ever the F# Interactive executable outputs a line. The control has basic REPL semantics - user enters a line of text, the line is executed and the output is printed to the screen. The F# Interactive window in Visual Studio is the implementation I'll be copying. I had a look around and found 'WPF Terminal' on CodePlex  it looked promising - fulfills the REPL requirements, until I realised it's using a TextBox  for the rendeing. With a TextBox the text can only be one colour and I need the ability to s...

In the first post I've managed to abstract the use of the F# interactive process behind an interface - it can now be used from an .net application: Loading gist .... The goal of the abstraction was to make it easy to use and I believe it has, but after reviewing the interface and implementation there will be responsiveness problems when I try and use it in an actual WPF UI. I reckon this because the F# interactive process is running ' out of process ' and the fact that any script I want to execute has to be written to the input stream and then interpreted & executed. This means there's going to be an appreciable delay in the responsiveness of the UI - a delay long enough to be observed by the user or at worst allow the user to enter another script before the previous has been executed and therefore screw up the output. This can be observed in the console test harness as well, if I enter text before the initial setup has been completed it screws up an erro...

This anti-pattern is probably more applicable to large MVVM based applications, and it might even just be a pet dislike of mine. I better clarify what I mean, this pattern is known by different terms, it's also known as Event Broker (PRISM). It shouldn't be confused with an enterprise message bus, what I'm talking about is a UI layer applicable pattern, which is used to communicate internally by the UI implementation. The UI might well still use an enterprise message bus to communicate with disparate backend systems. Shown below is a really simple interface & implementation of a message bus, this service would normally be a singleton instance shared between all view models & other services: Conceptually as you can see all it does is connect a publisher to a consumer on a particular topic. Now this a very powerful concept and when used well. It provides a clean way to communicate between disparate view models & services in the UI. For me the ability t...

This is another anti-pattern I've seen a lot recently, the dynamic use of the IoC container inside a view model to resolve child view models & services - service locator pattern: The service locator pattern has been around for a while - Fowler was writing about this back in 2004! It's not a pattern that is specific to MVVM, it's a pattern associated with using DI & IoC, if you're doing MVVM you should be using DI & IoC . A lot has also be written about this being an anti-pattern and I agree completely with Mark Seaman on the topic. For me why this is an anti-pattern for MVVM is for the following reasons: Breaks SOLID principles - the view model now has multiple responsibilities and not all dependencies are being explicitly injected. The view model is now responsible for the lifetime of anything it has resolved (this includes scope as well) , Encourages view models to become god-like objects - they become bloated - all the implementation in...

I've seen rather a lot of this anti-pattern recently, to be explicit about what I mean, lets define this in terms of a WPF user control. Imagine the code behind file is nothing more than the auto generated code, but the XAML file contains the usual controls and bindings: The user control is used in one or more data templates as follows: The reason this is an anti-pattern is because it has introduced files into the solution which aren't required: The two highlighted files are the user control files - XAML and code behind, the resources.xaml file contains the hosting data templates. The reason why these aren't required is because the code behind for the user control is doing nothing, and therefore can be removed and the XAML can be moved into the hosting data template - now the view (MVVM) is no more than a data template:  And you can now see the user control files have been removed from the solution:

I believe explicitly using the data context in the code behind of the view (custom, user control etc) in any MVVM application is an anti-pattern. The view has no need to explicitly access the data context it is there purely for binding concerns. The following screen shot illustrates what I mean: This is an anti-pattern because the view knows about the view model - as you can see the data context is being cast to the DataContextViewModel. The view (user control) is explicitly coupled to the view model and has reduced the cohesiveness of the view - it can now only be bound to instance of DataContextViewModel. Now you could argue if it was interface this would make is more useful but this doesn't reduce the tight coupling it just gives the illusion. I guess the reason why this is common is because it makes the XAML appear very clean and simple, but this is also not ideal because it's not obvious what's being bound between the view model and the view: How should this h...

I've blogged about implementing a busy indicator before, this post is an extension of this pattern to implement a message box - this is instead of using the namespace provide by the .Net framework. The UI is shown below, and when the button is clicked in the middle content it will display the message as an overlay - as you can see I've coloured it green to get your attention: As with the previous post , the XAML for the View hasn't changed it's still very simple: What's changed is the style applied to the ViewHost class, as you can see there's now a MessageOverlay as well as a BusyOverlay. You'll notice the z-order of the MessageOverlay is one less the BusyOverlay, this is to make sure the busy indicator is always displayed at the highest order and hence would be an overlay on top of the message overlay: The message overlay is trigger by the binding MessageMonitor, this is an implementation of the following interface, the one I'm using i...

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v...

Currently I'm working on a .Net 4.0 WPF app and we've had some discussion about moving to .Net 4.5, we don't get to make the decision :( but we're interested to know what performance gain we'd get. What follows is a comparison of the same app compiled against .Net 4.0 & 4.5. The app makes use of a couple of NuGet packages - Autofac & Reactive Extensions, both of which provide versions for both .Net 4.0 & 4.5. It also makes use of Telerik grid control to render the data. What does the app do? Pretty simple, it generates a 1000 rows of data asynchronously and binds this to a telerik grid, for every iteration the grid is clear of any data first. How am I going to measure any performance improvement? I'm using the code from a previous post - ' Measuring UI Freeze... ', I'm expecting any improvement to be visible in a reduced amount of time on the dispatcher thread - if the (.Net) code base is more efficient it should surely redu...