Awkward Coder

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

Making sure an application doesn't freeze the UI is probably one of the most important concerns when building an application. UI freeze can be broken down into two categories,firstly long running background tasks and secondly the rendering of UI elements (controls) to the screen. The second situation is what interests me with this post, usually UI based applications will dedicate a single thread to rendering the UI (dispatcher). This thread in theory can become overloaded with work and therefore the UI  becomes unresponsive to the user until the work is completed - the app freezes. Measuring this freeze on the dispatcher is useful in diagnosing the problems of rendering large amounts of data in a short time frame, e.g. like trying to render a large number of rows in a grid. How can I measure this freeze? You can do this easily with a couple of Rx methods: Loading .... The key is making sure they execute on the dispatcher thread. This ensures that when the dispatcher is ov