Tab controls and tree/grid controls – why change them?
In this post I’m going to describe some of the changes we’ve been making to the user interface of our software tools and also why this change has become necessary.
A mish-mash of competing control types
Over the past few months we have made a variety of wide ranging changes to the GUI of our software tools. Earlier versions of our tools used some 3rd party tab controls and some 3rd party grid controls that could also function as tree controls. These controls were very useful and enabled us rapidly create the user interfaces we needed.
However, over time we found a few special cases where we needed something more powerful. This resulted in the virtual tree/grid control we now use to display the potentially very large datasets the tools can collect. We haven’t found any 3rd party tree or grid that can handle the volume of data the virtual tree/grid control can handle.
The result of this is that there were several competing styles of tree/grid control, some with white backgrounds, others with darker backgrounds, all with different visual styles for the way the grid was draw and the way it behaved in response to user input. This, while effective, was less than ideal.
Assessing the possibility of new platforms
At the same time, we have customers and potential customers asking us when our software will run on 64 bit Windows, or when it will run on Linux and Mac OS / X. We’ve been looking at the Linux and Mac OS / X issue for some time, evaluating which technology route to go with for the port, writing tools to automate as much of the port as possible (we have over 30 software tools to port if we port every tool) and assessing the “weak points” in our codebase that will cause us trouble.
Some customers having become used to our rapid turnaround of bug fixes have been somewhat surprised at how long we have taken to produce our ports to non-Windows operating systems. The main reason for the delay is that we want to port all the software tools that are appropriate, rather than just port Ruby Performance Validator and Ruby Memory Validator.
Getting to a consistent set of controls
Having written the porting tools, we then ran up against our major weak points, consisting of the 3rd party tab control and 3rd part tree/grid controls, used in many, many places throughout our software. Thus, alongside our usual development goals of introducing new functionality and attending to customer issues, 2008 has been spent writing even more tools to aid us with the transition from the 3rd party tab control to a custom tab control and from the 3rd party tree/grid control to the virtual tree/grid control.
Today marks the first day without the 3rd party controls in our software. We still have some work to do before we can let the automated porting tools we’ve written loose on our codebase to product the cross-platform single source codebase we desire. However this is a significant step forward in that process.
Although we are not there yet, I hope this posting has provided some insight to what we are doing to those of you that are interested in this work.
Future postings will cover this topic as we have more to say about porting from a large MFC codebase to Linux and Mac OS / X.