Awkward Coder

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

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

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

Received what at the time seemed like a strange exception from a piece of code in a silverlight I was debugging yesterday - ' this operation can only occur on the ui thread. ' What makes this strange was the fact this wasn't attempting to update any UI controls or classes bound to views,  infact this was the complete opposite, this was a method trying to invoke out to javascript from a randomly assigned thread (thread pool). To compound my confusion not only was I seeing this intermittently but the action I was trying to achieve still appeared to completely successfully, writing to an in-memory javascript log! Now the answer is as you probably known, is... Any interaction with the host browser from silverlight has to be done on the UI thread even if you're not updating any UI.