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...

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...