Awkward Coder

Outlook AdvanceSearch API not returning latest emails in the results

2023-11-08T17:43:00.002+00:00

Using Office Interop AdvanceSearch API method to query a Outlook folder isn't returning all the results, it's only returning results from 2 days ago!

This code been running fine for over 2 years why is it failing now, and only failing on one machine?

Turnsout the it's a new machine after the last one died a couple of days ago, and this lead me to the answer - Indexes...

The indexes hadn't finished re-building from the last retore point, and if you use API before the Indexes are built you might not get all the results.

If you dig into the Indexing Options it even tells you this, shame the API can't surface this warning.

SqlDependency - getting the permissions working...

2023-10-12T12:11:00.005+01:00

After much banging my head against the internet here is a canonical example of how to configure SQL Server permissions, roles to get SqlDependency working in a .Net app.

This is for sceneario where the identity running the .Net code is running as a configured user account with the db_datareader & db_datawriter.

-- Create Schema User
CREATE USER sql_dependency_schema_owner WITHOUT LOGIN;
GO

-- Create Schema for SqlDependency objects
CREATE SCHEMA sql_dependency AUTHORIZATION sql_dependency_schema_owner;
GO

-- Create Role for users of [sql_dependency]
CREATE ROLE sql_dependency_user;
GO

-- Grant role permissions
GRANT CONTROL ON SCHEMA::sql_dependency TO sql_dependency_user;
GRANT IMPERSONATE ON USER::sql_dependency_schema_owner TO sql_dependency_user;
GRANT CREATE PROCEDURE TO sql_dependency_user;
GRANT CREATE QUEUE TO sql_dependency_user;
GRANT CREATE SERVICE TO sql_dependency_user;
GRANT REFERENCES ON CONTRACT::[http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification] TO sql_dependency_user;
GRANT VIEW DEFINITION TO sql_dependency_user;
GRANT SELECT to sql_dependency_user;
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO sql_dependency_user;
GRANT RECEIVE ON QueryNotificationErrorsQueue TO sql_dependency_user;
GO

-- Set [sql_dependency] as user default schema add to role, example user 'ollie'
ALTER USER ollie WITH DEFAULT_SCHEMA = sql_dependency;
ALTER ROLE sql_dependency_user ADD MEMBER ollie;
GO

Clean app startup (WPF)

2022-06-29T17:59:00.007+01:00

Simple easy to read code is the building blocks for complex applications, and to this end, the is how I now start all desktop apps (written in XAML / WPF). This is nothing new (and not original) but it's been refined & destilled down to a point of simpliclity :)

Single line written once and forgotten about...

Need to add Exception handling - write it in a Module...

Need to add Heartbeat monitoring - write it in a Module...

Using DI - do it in a Module...

Startup XAML - guess what, done in a Module...

Want only one instance of the app - do it in a Module...

So lifting from my updated Simple.Wpf.Template on gitHub, I have the following set of Modules defined - this forms the basis for all apps I'm asked to develop for clients:

The complexity is hidden away in the ModuleLoader class, simple put this scans & loads any type with the ModuleConfigurationAttribute, orders the Modules according to the properties of the Attribute and dynamically invokes the Modules.

Check out the code here...

Benchmarking DateTime.ToString("...")

2022-06-17T16:15:00.010+01:00

Looking to eek-out as much perf as I can from some code (C#) at work, and looking at all the .ToString() manipulations in the code and I came across the following:

How can I quickly workout if I want to do something around this?

BenchmarkDotNet to the rescue, and this library really does make benchmarking easy (and fun!). I created an overload of the extension method which internally uses a cache to avoid the repeative ToString() calls:

Only small issue was wanting to test a Static methods, and this only involved creating a wrapper class with annotated methods(calling the static implementations), also preloaded the internal cache:

Results below, make-of-it what you will...

Rx EventAggregator<T> for desktop apps

2022-06-13T15:40:00.006+01:00

In my continuing (point-less) mission to avoid using anything related to MS Prism - a quick implementation of an EventAggregator using Rx - took about 5 minutes to write for a problem I currently have, normally try and avoid using such a pattern as it can lead the scattering of business logic which can hard to 'follow' when refactoring / re-visting code.

Trying to kepp the interace as simple and obvious as possible (symetric design) - this will be injected by the container:

Simple base event class, not thing special at the moment, might add a timestamp in the future, but more likely to do that with Rx on the event stream using the apply named Timestamp method:

Included a simplifed Schedulers wrapper - idea being you can get any of the Rx Schedulers in one place, and importantly makes unit testing easier:

Show me the money...

Getting the last column to fit to available space in slickGrid

2021-09-20T10:34:00.000+01:00

I wanted a quick diagnostics page in html / js and this included grid to show server logs, decided to use slickGrid. All pretty easy to use apart from one thing - last column to fill remaining space...

Nothing in their examples, so here's one for posterity...

Not sure if it's the preferred way, but it works - the most obivous issue for is doing a DOM search to get the Viewport element - this is tightly coupled to the current latest release.

Stuck the implmentation in a Class and not provided any logic for creating Data, Columns or other grid optnios / plugins - tried to keep it simple...

Custom AuthorizationHandler for SignalR Hubs

2021-08-06T14:01:00.004+01:00

How to implement IAuthorizationRequirement for SignalR in Asp.Net Core v5.0

Been battling this for a couple of days, and eventually ended up raising an issue on Asp.Net Core gitHub to find the answer.

Wanting to do some custom authorization on a SignalR Hub when the client makes a connection (Hub is created) and when an endpoint (Hub method) is called:

I was assuming I could use the same Policy for both class & method attributes, but it ain't so - not because you can't, because you need the signatures to be different.

Method implementation has a resource type of HubInnovationContext:

I assumed class implementation would have a resource type of HubConnectionContext - client connects etc... This isn't the case, it's infact of type DefaultHttpContext. For me I don't even need that, it can be removed completely from the inheritence signature and override implementation.

Only other thing to note, and this could be a biggy, is the ordering of the statements in the Startup class:

AutoFac for SignalR using ASP.NET Core version 5.0

2021-07-09T13:16:00.006+01:00

Putting this here, so it might help someone else in the future!

Couldn't find an example for version 5 of ASP.NET Core - the number of breaking changes in ASP.NET Core is incredible, and a big negative for the framework when looking to integrate 3rd party services such as logging & IOC.

Steps:

1. Add nuGet packages:

Autofac
Autofac.Extensions.DependencyInjection

2. Update Program.cs file to add AutoFac Factory:

Highlighted the import part in Red:

3. Update Startup.cs file to add AutoFac container configuration:

Highlighted the import part in Red:

IRegisterService & IRegisterHub are interfaces I created for easy registration with AutoFac.

WPF tips & tricks: Dispatcher thread performance

2016-06-21T21:28:00.000+01:00

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data.

I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app.

First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :)

So, what do I mean by 'Dispatcher thread performance'?

The 'dispatcher thread' or the 'UI thread' is ~~probably~~ the most important thread in any WPF app, and making sure this is working efficiently should be one of the primary concerns of any WPF developer, if not you'll end up in a situation which has prompted me back to life.

The code below doesn't improve efficiency, it allows you to observe when the dispatcher thread is overloaded with work, it has to much work to do in the time available, this manifests it's self as an application freezing & stalling for an end user - also known as 'white screen of death'.

private static IDisposable ObserveUiFreeze()
{
    var timer = new DispatcherTimer(DispatcherPriority.Normal)
    {
        Interval = TimeSpan.FromMilliseconds(333)
    };

    var previous = DateTime.Now;
    timer.Tick += (sender, args) =>
    {
        var current = DateTime.Now;
        var delta = current - previous;
        previous = current;

        if (delta > TimeSpan.FromMilliseconds(500))
        {
            Debug.WriteLine("UI Freeze = {0} ms", delta.TotalMilliseconds);
        }
    };

    timer.Start();
    return Disposable.Create(timer.Stop);
}

So, how does this code work?

Very simply really, by using a dispatcher timer to tick every 333 ms, it will always fire every 333ms irrespective of anything else, but this doesn't mean the Tick handler will receive the event in a timely manner and this is the key point. If it doesn't receive the event in a timely manner it means the dispatcher thread is overloaded with work and can't refresh the UI quick enough. The Tick handler evaluates the delta between the current & previous times, and if this is greater than 500ms it will write out to console window (in VS or DebugView).

Example output from VS is shown below, this is using the publicly available WPF template project I use as a starting point for most apps. I've highlighted the line of interest:

The output was forced by placing a Thread.Sleep call in the Refresh button handler in the ViewModel:

Hopefully you now see this gives an easy way to diagnose problems with overloading the dispatcher thread.

WPF anti-pattern: Docking panels

2015-04-28T21:24:00.002+01:00

Developers love docking panels (especially Windows developers), they love the ability to 'dock' a panel to the left, top, right bottom of the window, and repeat this with windows inside windows inside windows ad infinitum...

Shown below is the docking ability in Visual Studio - it works great because the target user has the required level of understanding of a complex app.

The problem is the majority of users haven't got a clue about them...

When they accidentally drag a tab or window and the UI suddenly show docking points like the above screen shot they haven't got a clue what to do to get back to where they were. This coupled with the look on their faces makes me think the use of docking panels should be avoid in all but the most complicated apps - the average business line app developed using WPF doesn't really need a docking panel.

I call the use of docking panels in general an anti-pattern :)

Styling WPF buttons for Image Viewer

2015-01-08T13:24:00.000+00:00

A quick post on styling the next & previous buttons for an Image Viewer written in WPF, I'm using the MahApps libraries to give the UI a modern look & feel - they are available as nuget packages, I'm using the core and resources packages.

The initial version is very simple and hopefully the behaviour is obvious - the image flanked by a couple of buttons for moving to the next\previous image:

The XAML for this is very simple, using grid layout to achieve the alignment required, one thing to note is the Stretch characteristics of the Image control - the image ratio will be maintained as the app is resized. Also I'm using the default (implicit) styling for the button controls, these come from the MahApps libraries:

The next iteration sees the 'cleaning up' of the actual UI elements - the removal of border from around all the controls and the applying of the flat button style to the next & previous buttons.

The other majors changes are the replacement of the 'next' & 'previous' text with a couple of icons implemented as Path embedded on a Canvas, and the moving of the buttons to on top of the image - this obviously is now not ideal because it's obscuring parts of the image:

The XAML has changed subtly, the Image now spans all the columns in the Grid and each Button content has been replaced with a styled VisualBrush:

The Visual for the next button is defined as follows:

The final version isn't that different to the previous, the most obvious change is the use of Property Triggers to control the Opacity of the buttons - the buttons only become visible when the mouse is moved over there location, this means for the majority of the time the whole image will be visible and not obscured by the buttons.

The XAML is now simpler - mainly because the styling has been abstracted away into a separate style resource dictionary:

The complexity (which isn't very complex really) is moved into the styling for the buttons:

UI freezing when CPU hits 100% constantly - follow up, part deux

2014-12-17T19:53:00.002+00:00

My last post had a comment from @LordHanson about changing the thread priority via the ThreadStart parameter to see if this improved the performance.

I made the following small change to include setting the thread priority:

This improved the responsiveness of the UI when the number of thread is equal to or greater than the number of logical processors (tested with 2 * System.Environment.ProcessorCount), I still see the UI stuttering & stalling occasionally but it's greatly reduced - happens less than 10% of the time.

I then start to wonder is it better from the point of view of total time taken to reduce the concurrency to less than the number of logical processors or to reduce the thread priority. I suppose the answer depends on which technique you want to use, for me there isn't a justifiable reason not to use the Parallel.For from the TPL - it's not a piece of time critical code.

UI freezing when CPU hits 100% constantly - follow up

2014-12-15T18:16:00.001+00:00

I was wondering on the affects if my previous post was re-written to remove the use of TPL and just use the standard threading classes in the framework instead, would the performance be different.

So the previous post was using the following code:

When the limited concurrency scheduler is initialised with a number greater than or equal to the number of logical processors then the CPU hits 100% and the app stalls and stutters.

If this is re-written without the use of TPL would I get the same results?

Re-writing this produced the following code, using a Semaphore to control the number of concurrent threads:

In answer to the question, you get exactly the same behaviour, there is no benefit in not using TPL to handle the concurrency - good :)

UI freezing when CPU hits 100% constantly

2014-11-16T16:34:00.000+00:00

I've been working with a team where I've been putting a WPF UI over a set of implementations of a custom interface. Each implementation is a long running process which is handled in standard manner by creating an asynchronous Task<T> and displaying the results from the continuation.

The standard CPU utilisation for the majority of the interface implementations is shown below - this represent the ideal, not hogging the CPU's and behaving like a good citizen...

Where as one implementation has the following CPU utilisation - all logical processors max'ed out. The app becomes unresponsive, the UI starts to stutter and freeze all because the dispatcher (UI) thread is not being scheduled frequently enough - white screen of death (WSoD). It's not only this app it starts to affect but all other apps running.

Hopefully the difference between the majority and this particular instance is obvious - the majority are single-threaded long running processes and the other is a multi-threaded long running process. It is not multi-threaded by a factor 2, 3 or 4, but by a factor of n, where n is considerably larger than the number of available logical processors, a value greater than 100.

The code causing this issue is generating simulation data for a set of stochastic models, the generation is CPU bound for around 5 minutes, after that the long running process returns to be being a single-threaded and behaves like all the other implementations, I can't show the actual code, but shown below is something similar:

As you can see the for-loop creates a lot of tasks - 1000 in the example. The method then waits for all of them to complete before returning.

The scheduling of tasks (onto the logical processors) can be configured, but in this case it isn't and this is the problem, the default method overload has been usēd.

Because we aren't attempting to control the number of concurrent tasks running the TPL is maximizing the number of tasks, in this case it's running 8 in parallel across the logical processors until all the scheduled tasks have completed.

How do I control the level of concurrency for so many tasks?

The overloads for StartNew on the TaskFactory class doesn't expose an obvious solution such as an integer value for the maximum concurrency. The answer is to pass a custom scheduler to the method which it controls the level of concurrency. MSDN has an article on the subject, and it's perfectly suited to this problem. The modified method now looks like this:

I've hardcoded the maximum number of concurrency to 6 in the above example, but you could do something more dynamic by using the System.Environment.ProcessorCount property. The CPU utilisation now looks something like this:

The CPU utilisation is now around 75% which represent the level of concurrency I've specified with the scheduler - it was created with a concurrency of 6 (out of possible 8 logical processors). This still seems rather large, but there is enough spare capacity for the dispatcher thread to be scheduled and therefore the UI remains responsive.

Note: The code above could be re-written to be more elegant using Parallel.For method, this would remove the need for the custom scheduler - it's not my code to change apparently :)

If I was to re-write it, something like this following would be better IMO:

More info about the differences can be found in the following pdf, Pattern of Parallel Programming in C# for info on Parallel.ForEach vs Task.Factory.StartNew.

Modelling units of measure

2014-11-06T18:46:00.002+00:00

I've been looking at writing an exercise app, and this would require some kind of units of measure for distance (as well as time).

I could use an enum to represent the different types of units - metres, kilometres, yards, miles etc. But this seems to be lacking from the point of view of converting between the different types - I would need a class to represent the conversions. What I want is a more integrated approach - the use of static read-only properties.

What I want to be able to do is best described by the following test:

The Measurement struct is very simple, a couple of properties - Amount & Unit and a ConvertTo method:

As you can see in the ConvertTo method the Unit class owns the conversions - it is more than just a simple Enum - it has behaviour, how to convert between the different units of measure.

So how are the units defined?

A Unit instance is exposed as a read-only static property on a static Units class:

What makes this approach interesting is the use of the Lazy<T> to get around the circular reference problem when the static properties are initialized - for example the Centimetre properties uses the Metre & Kilometre properties which in turn use the Centimetre property, which in turn use the Metre & Kilometre properties.

As you can see this could go on for ever if I didn't use the Lazy<T> inside the Unit class. It allows me to disconnect the creation of the conversions from the Converters property because by the time the Converters properties is accessed the constructor on the Unit class will have completed.

The smart bit of code is inside the Converters property, a pretty standard piece of lazy initialization to create the actual Converter instances.

The code above is from the Simple.Units repo available on GitHub

Simple F# REPL in WPF - part 4

2014-01-18T23:37:00.000+00:00

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 referenced above:

For completeness the types used in the above query are shown below:

How is the user control being used in code?

The user control obviously has an XAML representation - ReplEngine. I've tried to keep the using of this as simple as possible, the following screen shot shows the control being used in an MVVM implementation with a specific theme being applied:

The control's DataContext is bound to specific view model supplied as part of the assembly. In fact if your going use the control in an MVVM application there are 3 classes you'll need to know about and use:

ReplEngine - as described above the UI representation of the REPL engine to be included in XAML,

ReplEngineController - coordinates communication between the UI and the actual REPL engine implementation, backed by an interface - IReplEngineController,

ReplEngineViewModel - contains all the UI concerns, bindable properties & commands, backed by an interface IReplEngineViewModel and accessed from the controller.

The view model (FSharpReplViewModel) used is shown below and as you can see it's using both the controller & view model, nothing complicated just simple dependency injection and exposure of the view model as the Content property:

The IoC registrations for the controller & view model are easy, as you can see there are couple of parameters, these are optional, this is where you'd configure the working folder and the script to run automatically when the UI is first rendered:

As you can see, it's really quick & simple to use in an MVVM scenario, but;

What if you're not using MVVM, what if you're using a code-behind approach?

This is catered for as well in the form of a user control called ReplWindow. This wraps the ReplEngine user control, the controller & the view model, meaning you don't have to bind any properties. The StartupScript & WorkingDirectory are exposed as dependency properties:

That's it from a hosting point of view, the only thing left to describe is the theme support, not so much describe but show a hideous green example and the supporting XAML:

The theme styles the buttons, border, text & terminal controls, if a theme is not defined it will default to the current windows theme:

Loading gist ....

The example app used above is from the Simple.Wpf.Composition repo available on gitHub.

Managing themes in WPF

2014-01-02T19:00:00.000+00:00

Having just published Simple.Wpf.Terminal as a nuget package I wanted the ability to skin the user control - the more flexibility in the way it looks the more likely it will be used by other devs :)

Before getting into the detail, lets look at the solution working in the test harness for my WPF F# REPL Engine, shown below are four different themes applied dynamically at run-time - no recompilation required to change the theme:

Previously in larger WPF apps I've relied upon third-party control vendors like Telerik to provide theming support. Typically they provide good solutions to the problem with multiple themes supported as standard, and when you're already using their third party controls the use of their themes makes sense. But when you're developing a small UI component you don't want to add (& support) such a large footprint just to add themes to your niche control.

A theme is a collection of Styles grouped into a ResourceDictionary in WPF. A Style can be applied to a control type, this is done either via the target type of via name (Key). Shown below is a very simple there with two styles defined, hopefully they are obvious but if not these two styles are targeting the Button & TextBlock controls:

A theme (resource dictionary) is then applied either at the application level to all controls in the visual tree or at the control level to all controls lower in the visual tree - scoping the theme to only a part of the visual tree.

How you apply the theme is what makes managing themes interesting, typically in an app which doesn't support changing the theme at run-time this would be done statically at compile time using XAML:

But this approach won't work when you want to be able to change the theme dynamically at run-time, you need to do this in code behind, and this is where a theme manager comes into play.

The solution I wanted was to provide a simple UI (combo box) allowing the user to select a theme which is then dynamically applied to the UI. The UI control manipulates a globally defined theme manager - defined globally as a static class:

The control exposes three dependency properties - ItemsSource, SelectedItem & Scope.

These allow the setting, selecting and scoping of the theme you want to apply to the app. As stated earlier the actual manipulating was done using a theme manager class, this means you aren't required to use UI (combo box) to manage themes. The theme manager implementation is shown below, as you can see it's pretty straight forward manipulation of resource dictionaries:

Loading gist ....

The following example shows how I use the control in a code-behind approach - there's an MVVM approach included in the code base on github:

with the following code behind, note the use of the Theme class to bring to together the user friendly name and the actual URI of the resource dictionary:

and finally the following XAML definition:

Hopefully you can see you don't need to actually use the ThemeManager class directly, this is done for you by the Theme user control.

I've pushed the code up onto github and as a nuget package.

Simple F# REPL in WPF - part 3

2013-12-27T21:13:00.000+00:00

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 show errors in a different colour. Also I wanted the ability to define the terminal prompt used.

I realised I needed to use a RichTextBox to get the UI behaviour I wanted, this meant writing my own control.

Before showing the key parts of the implementation, lets look at the finished control used in a couple of test apps:

This has the following XAML definition, as you can see it's using several custom dependency properties, these are explained later:

Another example used as a log window (inside a WPF app):

And this has the following XAML definition:

Hopefully it's obvious looking at these two different uses that there isn't any implementation inside the control apart from how to show the bound data (ItemsSource property) - the control only deals with UI concerns, as any View in an MVC implementation should only do.

What does the implementation look like?

As I said earlier, this control derives from RichTextBox, the derived class 'Terminal' defines the following event & dependancy properties - you can see some of these used in the above XAML screenshots:

Loading gist ....

Hopefully the use and behaviour of these is obvious, but if not the most important three are:

LineEntered - event is fired when ever the user press the Enter key,

Line - currently entered line by the user,

ItemsSource - data displayed above the Line, this would be a collection implementing the IEnumerable interface, you can define the ItemDisplayPath if you're binding a complex type not a simple type (string).

I'm not going to show the complete implementation because it's over 600 lines, but the most important method is the intercepting of every key press using the override OnPreviewKeyDown. This allows the control to prevent or allow certain key presses:

When dealing with a RichTextBox you have to understand the content you see on the screen isn't what you're going to manipulate when you're trying to add, remove or edit content. You do this using instances of a TextPointer - they represent a position within in the FlowDocument of the RichTextBox.

The constructor is shown below, as you can see I'm creating the FlowDocument with a Paragraph, it then adds a Run which represents the Prompt in the UI, doing this allows the manipulation of the content later. This is because from a terminal window point of view the text entered after prompt is the important part:

The following screenshot shows the delete key handler, it's probably the simplest key handler in the control, all it does is compare the current caret position to the end of the prompt and if it is greater than the caret then the delete key can be processed:

I've pushed the code into the wild as both a GitHub repo and as a nuget package.

In the next part of this series I'll bring it all together in an MVVM based solution.

Note: The F# Interactive screen shot was taken from the Simple.Wpf.FSharp.Repl GitHub repo.

Note: The log window screen shot was taken from the Simple.Wpf.Composition GitHub repo, select 'Logging Workspace' from the drop down and click Add.

Simple F# REPL in WPF - part 2

2013-12-19T22:39:00.000+00:00

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 error - I've highlighted the text and the error it generated:

In a UI based application you typically disable controls when you want to prevent the user from entering text (data) when it's not applicable - using XAML framework properties like IsEnabled or IsReadOnly.

Exposing information to manipulate the XAML properties will be key to preventing user input at the wrong times during the engine execution cycle. Currently the interface doesn't expose any information about the current state of the F# interactive process - the name of the interface should have given me a clue, it contains the word 'engine'. Engines usually have a set of predefined states - stopped, starting, stated, idling etc.

I need to expose state of the REPL engine through the interface - this will allow me to enable\disable controls in any WPF UI. I've decided on the following states and these are exposed via an IObservable<state> property on the interface called 'State':

Loading gist ....

The observable property will pump when ever there is a state change in the engine and this will allow any UI to do what ever it wants when a state transition occurs. Implementing this in the engine is easy, in fact it improves the implementation because the control flow is easier to understand, shown below is the implementation of the Stop method:

Loading gist ....

Hooking this new property up in the console test harness is easy:

When running this produces the following results in the output window of visual studio:

The future WPF UI will disable the ability to execute a script while the state is not equal to 'Running'.

In the next post I'll actually get around to using the implementation in WPF :)

Simple F# REPL in WPF - part 1

2013-12-15T21:22:00.002+00:00

I'm currently working on a C# WPF app which makes use of F# as a modelling language to dynamically create data points from static data in the system. The user enters the F# in the UI via a code editor window, it is then validated & compiled by back-end services for use in reporting & charting views. This all works well but the feedback loop is rather long - instead of being seconds it can take a couple of minutes! What would be nice is a REPL window in the UI, which would allow the user to test the F# code snippet they've just created without having to communicate with the back-end services.

What follows is the first in a set of posts (not sure how many there will be) in the creating of a simple F# REPL UI for use in an WPF app - the end goal is to be able to include a WPF user control in a XAML data template.

The F# interactive window in Visual Studio is done using the fsi.exe executable, this functionality is what I want to achieve in any WPF app - the ability for the user to enter some F# code and execute and get the results displayed immediately.

The F# interactive (fsi.exe) executable provide in visual studio is own & copyrighted by Mircosoft so using this is out of the question. Fortunately F# has been open sourced and is available here - I'll be using the latest version of the F# code base (v3.0).

Shown below is the F# interactive window from visual studio, and as you can I see I've enter a simple F# expression which has been executed - let answer = 42.00;;

Menu: View -> Other Windows -> F# Interactive.

My goal for this post is to use the F# interactive executable behind the following interface - this will then allow me to easily host and use the F# interactive executable in any .net app in the future - for this post the host will be a console application:

I'm using Reactive Extensions to expose the output from the F# interactive executable to the host app. Hopefully the interface is self explanatory - but if not, the idea is you will start the F# REPL engine and then 'Execute' F# scripts, and you observe any output via the Rx stream exposed as the 'Output' property.

Just like in visual studio I'll be using the F# interactive as an out of process executable and manipulating the standard input & output streams to communicate. This is done using an instance of the Process class and redirecting the input & output streams, shown below is how I'm creating the F# interactive process:

The input stream is used as follows - the stream used to send text input to the process:

Using the output stream is a little more complicated because reading a line of text from the process is a blocking operation in v4.0 of .net - a simple extension method gets around this issue:

As you can see this is an infinite loop - it will block the calling thread until the cancel is called on the CancellationTokenSource. To avoid this the code is executed asynchronously using the Rx method Observable.Start, below is the complete method block for reading the output stream:

The complete REPL engine is shown below, the F# interactive process is created on the calling thread with the output stream observed on a task pool thread using Rx. There is logic to safely shutdown process & background thread. The API isn't designed to be thread-safe as I'll be using this in a WPF app and it will only be called from the UI (dispatcher) thread.

Loading ....

The required F# interactive binaries will be added as a 'solution folder' because I couldn't find a relevant nuget package - hopefully I've just not been able to find it:

Testing this is now easy in a simple console test harness, it's a bit strange to use a console app to test another console app which has been wrapped behind an interface but it demonstrates perfectly how easy this will be from WPF:

Loading ....

With output looking very similar to the F# interactive executable, the only difference is the name of the executable in the title bar:

I've pushed the code up onto github, I'll be adding the WPF parts to the code base over the next couple of posts.

MVVM anti-pattern: Using UI Message Bus to communicate between View Models & Services

2013-12-11T21:50:00.001+00:00

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 to communicate this way, cross-cutting any structure you have for the view models, services & controllers seems wrong - when you've gone to the effort to separate out the classes and logically grouped them this all seems to be undone by using a message bus.

In larger MVVM applications you're more likely to have a controller sitting behind your main view model to orchestrate service communication and interaction between view models & services, and this is probably why I see this as an anti-pattern because it can destroy this structure. It almost could be considered another way to do the Service Locator pattern.

Another downside (just as important IMO) comes when you're debugging or re-factoring a code base - how difficult can it be to find where a message came from or which subscriber is causing an issue, especially when the call stack has been lost because the subscriber is handling the message on another thread.

MVVM anti-pattern: Injecting the IoC container into a View Model

2013-11-28T23:17:00.002+00:00

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 a single view model, it's no better than a testable code-behind file,

Makes unit testing brittle - when having to test such a view model you have either look through the whole class to see all the dependancies you need to mock or just try a 'hit & hope' approach and keep running and refeactoring the test until it passes. Either way you end up with a lot of test setup which is a smell in it's own right and importantly greatly discourages a developer to write tests,

And generally destroys the structure and ethos of the MVC (MVVM) pattern - if I can resolve anything anywhere eventually you'll end up with spaghetti code which has no discernable architecture and for me this is probably the most important point when dealing with a large XAML application.

What's also interesting about the above example is the fact it actually mixes normal DI with service locator, injecting both other interfaces as well as the IContainer interface - neither one nor the other. The example wasn't contrived to do this it was taken from a real world example - with names changed to protect the innocent.

There are times when I believe using the service locator pattern is justified, but these are few and far between. An obvious one is when the creation of a class is costly in time or memory (if this was ever the scenario for me with a view model it would be a code smell and need to be refactored out).

But if I had to use a service locator I would be either injecting a strongly typed factory or by injecting a Func<T> - all IoC containers support this feature. A couple of examples are shown below:

MVVM anti-pattern: View code behind with no implementation

2013-11-18T22:13:00.002+00:00

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:

MVVM anti-pattern: explicitly using data context in View code behind

2013-11-17T13:41:00.001+00:00

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 have been done?

By defining a Dependancy Property on the view (user control) and then binding this in the XAML to the FirstNames property of the view model, then there is no need to access the DataContext in the code behind of the view:

The XAML has now changed to be more declarative, which is a good thing:)

Implementing a message box using a visual overlay in MVVM

2013-11-10T16:29:00.000+00:00

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 is shown below along with interface:

Loading ....

What you see is the message is exposed as a view model implementing the IMessageViewModel interface, the implementation I'm using is shown below as you can see I'm injecting in the actual message and the busy indicator, I use these to simulate an action when the 'Show Busy & Close' button is clicked.

Loading ....

The code is available for download from github.