Use Mole 2010 to explore data from the F# Interactive console

I got an interesting e-mail today from someone interested in Mole 2010. He wanted to know how to open Mole 2010 to visualize the data in his F# Interactive console. I didn’t really understand what he meant at first, but this evening I researched it and found a solution for him. According to the fellow who sent me the e-mail, the F# community has been itching for a tool that they can use to visualize their data while working on the F# command line, so hopefully this will satisfy their needs.

I wrote up a short walkthrough document on how to use Mole 2010 in the F# Interactive console. If you are interested, please download it here: Mole 2010 in F# Interactive

I’m not an F# developer by any means, so please pardon any glaring stupidities in my F# code snippets. If you know a better way to write that code, I’m open for suggestions. 🙂

Note: This usage scenario is definitely not supported by Molosoft at this time. Mole 2010 and Visual Studio’s debugger visualizer infrastructure were not designed to work in the F# Interactive console. Please see this as an “experimental” solution to the problem. I’ve listed some  known issues in the walkthrough document.

Happy Moling!

Advertisement

John Liao on WPF and F#

A few months ago, I explored how the new .NET functional programming language F# could be used with WPF.  After a while I decided that F# was not “there yet”, in terms of Visual Studio integration, to really be a contender in that space.  One could say that WPF is not “there yet” either, but that’s besides the point…

It turns out that John Liao has down a fantastic job of exploring and blogging this exciting intersection of cutting edge technologies.  The mastermind behind F#, Don Syme, has created a listing of Liao’s WPF/F# blog posts here.  This is great material!  Enjoy.

Analyzing the visual tree in F#

I finally had my first “Aha!” moment with F# today.  After reading Robert Pickering’s amazing article about Erlang style message passing in F# I tried to create a very dumbed-down version of a function he created.  I wanted to create a function which counts how many instances there are of each type of element in a Window’s visual tree.

I’m using the WPF visual tree as a data structure to program against.  Since I can easily configure a visual tree via XAML, it makes for an excellent way to create a tree structure of diverse data types.  VisualTreeHelper is used to traverse that tree of elements, by calling its GetChildrenCount and GetChild methods.  This brings me to my “Aha!” moment…

In my previous post I recursively walked the visual tree by using a for loop, just like I would in C#.  But today that felt wrong.  I forced myself to drop my old habit of manually looping, and try to think about things differently.  As it turns out, F# makes it really easy to recursively walk down trees by using something called a “list comprehension.”  I used that feature to “declare” that I want a list of every child element of a given element, then I forward that list to the List.iter function.  The callback passed to List.iter contains the recursive call!  Check out the code in the countTypes function, where the comment reads “// Process this element’s children.”

The output of running the demo application contains the output of two functions.  The countTypes function output is listed second, as seen below:

I’m starting to really enjoy programming in F#.

Download the demo app here: Analyzing the visual tree in F# (demo project) Be sure to change the file extension from .DOC to .ZIP and then decompress the file.  Download the F# compiler and tools here.

Walking the visual tree in F#

This blog post shows how to dump the visual tree into a console window, using F#.

In my continued quest to understand how F# and WPF can work well together, I wrote a simple utility which walks down the visual tree of a UI and writes it out to a console window.  I found that F# is a natural fit for this type of quick script-like coding.  This app is not imminently useful, but it is a great way to both learn F# and get used to manipulating WPF with F#.

Here is the F# code:

Notice in the ‘createWindow’ function it uses the ‘use’ keyword.  That is a relatively new addition to the language, which you can read more about here.  It’s like a ‘using’ block in C#.

When the app runs, it loads a Window from a XAML file.  That XAML looks like this:

When you run the app, you will see both a console window and the window which was loaded from the XAML file.  Here is a screenshot:

Download the demo app here: Walk visual tree in F# (demo app)  Be sure to change the file extension from .DOC to .ZIP and then decompress the file.  Download the F# compiler and tools here.

Logging Routed Commands in F#

In my previous post I showed how to set up a generic technique for logging details about the execution of routed commands in a Window. That post’s demo app was written in C#. I’m trying to learn F# and explore how well it works as a language with which to program WPF applications, so I decided to re-write that demo in F#. Since I’m not at all proficient with F# yet (I’ve been studying it for less than a week), I had to drop a few aspects of the original demo simply because I have no clue how to implement them in F# yet!

If you want to run this demo app, you need to install the F# distributable. I am using version 1.9.2.9, which is available here. It can work with Visual Studio 2003, 2005, and 2008.

Here’s the Window1.xaml file:

Here’s the F# code (demo.fs):

If you compare this code with the C# code in my previous post, it’s immediately clear that we’re in a different world here. I cannot pre-compile my Window1 class into a BAML resource because F# projects have no notion of that. Instead I must load the XAML file from disk and pass it to XamlReader.Load to get the Window instantiated (that useful little function came from Robert Pickering’s book “Foundations of F#”). This also means that I cannot have a code-behind file for the Window1 class, unless there’s some trick I’m not aware of yet.

All of the code contained by the Window in the C# version now lives outside of it, because Visual Studio won’t let me have an F# code-behind file at this point in time. Eventually that might be addressed, but for now it kind of throws a monkey wrench into the whole “encapsulation” thing.

I really like how the calls to CommandManager functions in the attachedCommandLogger function are set up. The syntax for passing an anonymous function in F# is very nice, and I look forward to using the similarly elegant lamba syntax in C# 3.0 too. Since F# influenced many of the modern additions to C#, learning F# feels like killing two birds with one stone.

Programming in F# just feels “light” somehow. I like it.

I don’t think that this demo is in-depth enough yet to persuade me either for or against using F# with WPF. Once I have a better grasp on the language, and the concepts, I will be able to make a better decision about that. Until then I’m just enjoying WPF and F#!!

You can download the demo app here: Command Logging in F# (demo app) Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

WPF in F#

My blog has been quiet these days, for a few reasons, but mostly because I am excited about learning F#. In case you have never heard of it, F# is a new language being developed by Microsoft Research. Somasgear recently announced that Microsoft is investing heavily in F# and plans to make it a first-class .NET language, giving it full support in Visual Studio.

I was raised on C-based languages: C, C++, and C#. The concepts and syntax in F# are radically different from anything I am used to because it is largely influenced by OCaml, which is a functional programming language. F# is a hybrid of functional, object-oriented, and imperative programming languages.

Traditionally functional programming has been used for math-intensive programming problems; like financial analysis, and scientific computing. I’m not interested in learning F#, or functional programming, for that reason. What I want to know is if F# can be useful in the area of WPF programming, or, more generally, in front-end development. Are there sweet spots where F# and WPF will work together much more naturally and less verbosely than, say, C# and WPF? If so, what are those sweet spots and how can I introduce F# into my normal development workflow? If not, why not?

Robert Pickering, the author of the only F# book currently on the market, has posted some entries on his blog which use WPF and F# together. They’re not particularly useful examples, but interesting nonetheless. You can find them here and here.

Do you have any experience using F# and WPF together? If so, I’d love to hear more about it.