This is the eigth article in a twelve-part series that discusses the twelve finalists and their calculator submissions for the OMGWTF Programming Contest. The entries are being presented in the order submitted, and the winner will be announced on June 18, 2007.


If you’ve ever had the pleasure of working on or even using a giant, monolithic, internal application that was developed by the “crack team” of in-house programmers, then you’ll most certainly appreciate Entry #100252, Greg D’s Universal Calculator. It was designed to be the end-all/be-all of all calculators past, present, and future, and like the Titanic applications it was inspired by, the Universal Calculator fails at everything except being completely useless.

Like the architects of these in-house nightmares, Greg didn’t design his calculator around the requirements. Instead, he focused on building an extensible, “rock solid core” which the actual requirements – or, really, anything anyone could ever want, ever – could /then/ be built upon. A lot of “niceties” (such as a usable UI) risked compromising the purity of the framework’s design and were therefore moved to “Phase II.” This screenshot sums things up pretty nicely:

Downloading and running the application (100252-exe.zip, extract all then run exe) is highly recommended. There are just so many pointless features (that I’m sure sounded good at some point) that must be seen first hand: system tray status icon, tips-of-the-day, etc.

The reason that the linked program is contained within a Zip file is that there are three “plug-in libraries” that should run alongside the application: Numbers, Colors, and Pictures. All plug-ins to the Universal Calculator must introduce a set of Value Types that may be operated with any other Value Type. In other words, “6 + 3 / BLUE * {Picture of an Orange}” is a perfectly legitimate equation that returns a perfectly legitimate answer (this is why I encourage you to try it yourself).

And not only that, each plug-in is extensible in and of itself! Although most users may find the digits 0-9 to be satisfying, what if you want to add Z? Or €? Just select “Add New” from the dropdown list and go from there…

A further explanation of the “architecture” is in the project’s readme file:

  • DIGIT class: Represents a digit that can be entered via a button or the right combobox in the case of numbers, this is 0-9 by default, but because the number system may change at any time, the handy "New..." field allows entry of a new character.
  • VALUE class: Digits are entered into the display one at a time and may include any type. (Ex. 5BlueApple0372Green is a possible input) So, before any calculation can be performed, an array of DIGITs is converted into a VALUE object. If all of the types are the same, this is done automatically, but it can be manually performed in the GUI by clicking the "N" button. All this really does is convert all of the digits into the most common type in the array, then convert that into a value by invoking the VALUETYPE::GetValue() method. For numbers, this behaves pretty much as you would expect. For other types, not so much.
  • VALUETYPE class: Represents a digit/value type supported by a calculator plugin. A plugin implements this to provide the calculator application with information about what other types this type can convert to/from, and is also used to instantiate digits and values of the type.
  • PLUGIN class: Describes a plugin. Mainly this is used to provide access to the VALUETYPE object defined in a plugin, but it also includes methods for retrieving default digits that will be displayed in the right combobox initially, and a method invoked to allow the user to create a new digit of the plugin's type.
  • CALCCONTROL class: Lame OO wrapper for a custom control window class. Base class of DIGITBUTTON and VALUEDISPLAY.
  • DIGITBUTTON class: The stupid double-click push-button control used to display digits after the down arrow button is clicked. Guess where I got the idea for this.
  • VALUEDISPLAY class: Displays either an array of DIGIT objects or a single VALUE object.
  • PLUGINMANAGER class: Keeps track of loaded plugins and custom digits.

As for the Universal Calculator’s author, Greg is a fairly anonymous fellow. He was awarded a Bachelors in Computer Engineering from “University;” works at “Company,” which is large, multinational organization that does “Stuff;” and currently lives in a place called “City.” Greg did say, however, that he wanted to add a more complete picture plug-in and a sound plug-in, but just ran out of time. I will say, though, that the cuts in functionality certainly do add to the overall realism of the application.

But would Greg replace Window’s Calculator with the Universal Calculator?

Maybe. Maybe some day I’ll also start riding to work on a sideways bicycle. With handlebar warmers.

Download Entry #100252, Universal Calculator (ZIP File)

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!