Awkward Coder

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

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 - t he ability

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