We had an email from an irate customer complaining about the ugliness of the fonts in Resolver One. A quick investigation revealed that the Calibri font looks hideous; our own default is Tahoma, and we don’t tend to use Calibri internally, so we’d not really noticed — but because Calibri is the default in Microsoft Excel, an Excel import resulted in a horrible-looking spreadsheet. A further investigation revealed that this problem wasn’t just present in the grid component that we’re getting rid of: the same ugliness was present in the new, shiny grid that we are working on.

Our first thought was that it was a simple anti-alias issue and that we could fix it that way. The following screenshots show the dilemma we were faced with: The two settings (ClearType and AntiAliasGridFit) that made one of the fonts acceptable, made the other one ugly.

Resolver One with GDI+ and AntiAliasGridFit

Resolver One with GDI+ and ClearType

The second version is what you would see in the current version of Resolver One, and was also what you would have seen with the new grid if we’d not heard about this problem.

After some swearing and googling, Giles discovered this post that led us to the solution. We switched from using the DrawString method of System.Drawing.Graphics (which uses GDI+ to do the drawing) to DrawText on the System.Drawing.TextRenderer (which uses GDI to do the drawing). The result is that the two fonts look great:

Resolver One with GDI DrawText

An unexpected benefit is that another issue that we were worried about has also been solved: When switching to and from edit mode in a cell, the font appearance changed. This was a result of the switch from GDI rendering in the TextBox to the GDI+ rendering in the grid.

There are two lessons here:

• Harsh critics are your best friends when you’re writing software. Their criticisms improve your product. Listen to them.
• If you’re ever drawing stuff in .NET and it looks terrible, make sure you’re using the nasty old GDI API to do your drawing instead on the shiny, new GDI+ API.

Have you tried setting the Formatter on cells, rows, columns or worksheets? It’s a powerful way to change the way values are displayed without changing the values themselves.

For example, let’s say that you have a column full of distances in meters, but want to show them in miles. You can set a formatter like this:

def MetersAsMiles(distance, defaultFormatter):
    try:
        return "%s miles" % defaultFormatter(distance / 1609.344)
    except:
        return defaultFormatter(distance)
workbook["Sheet1"].Cols["Distance"].Formatter = MetersAsMiles

The first parameter to the formatter is the value to format, and the second is a reference to the function that Resolver One would normally use to format the value. Using that default formatter not only makes it easy to handle cases where your own code isn’t relevant (for example, when formatting non-numerical values in your “distance” column like the column header) — it also lets you take advantage of Resolver One’s normal formatting behaviour, for example by taking account of the number of decimal places specified in the “Format Number” dialog.

The formatter only affects the way the contents of a cell are displayed. For example, if a cell contained 18294, it might be formatted to and displayed as “11.37 miles”, but when referenced from another cell, the value would still be 18294.

We have had a number of queries about whether QuantLib works in Resolver One. QuantLib is “a free/open-source library for modeling, trading, and risk management in real-life.” We thought it would be great if we could confirm that it works with Resolver One. The short answer is: “It does!”.

Since a build of QuantLib and the .Net bindings can take most of a day (the bulk of it waiting for builds to complete), we decided to provide pre-built binaries and an example so our customers can try it out immediately.

As of version 1.5 (which is currently in beta), the world’s coolest spreadsheet can use Digipede Network grid computing to distribute and execute workbooks in parallel. The example on the Exchange is based on the excellent IronPython sample created by Robert W. Anderson of Digipede. The Digipede Network is a brilliant way to get distributed, parallel computation on Windows. It only took a few minor changes to convert Resolver One to run on the Digipede Network and to get the IronPython sample to execute Resolver One workbooks.

Digipede, like Resolver Systems, offer a  30 day trial of their software.

Now that we have released Resolver One 1.4 we are hard at work on features for the next version. We are also working on examples showing you how to use Resolver One in exciting new ways. One of the things that Resolver One makes possible is using the calculation engine to integrate your spreadsheets with other applications.

To make this easier, and demonstrate how it works, we’ve uploaded a Python module to the Resolver Exchange to help you use Resolver One workbooks (.rsl files) from IronPython scripts and applications.

• Using Resolver One Spreadsheets from IronPython Programs

This is a Python module that wraps the RunWorkbook function for easy use. The download include brief documentation and an example of how to use it. It exposes the same workbook object that you use in your spreadsheet user code, and RunWorkbook also allows you to pass in new data; turning spreadsheets into functions!

As well as embedding your spreadsheet into applications this also opens up interesting possibilities, like unit testing your spreadsheet logic. If you have any questions, or want to show off interesting things you’ve done with Resolver One, post them on the Resolver Forums.