As I sit here in my kitchen with a list of ideas for articles, contemplating which one to do first, the thought occurs to me that there is no better way to start a continuing series of articles about Castalia than with a brief history of how Castalia came to be.
In 1999, during my first year of college and right around the release of Delphi 5, I attended a Delphi user's group meeting in Phoenix. Danny Thorpe was the speaker, doing the requisite product demos to try and get us all to upgrade from Delphi 4 to Delphi 5, which didn't take much convincing, as any Delphi 4 user will attest. As is tradition when Borland employees speak, there were door prizes! I was one of the lucky ones who walked away with a bag of goodies including an Inprise (!) t-shirt, some software, and an issue of Delphi Informant magazine.
This is important because of one article in this particular issue of Delphi Informant. It was an article introducing the Delphi OpenTools API, a set of poorly documented features that allows developers to write extensions to the Delphi environment, which are called "experts." I thought this was interesting, so I worked through the demos from the magazine, and I was hooked! Being able to add features to Delphi was cool, even though I had no idea of what features ought to be added. I played with this capability frequently, never creating anything useful.
In 2000, I left Delphi, computers, and a lot of other things behind to do some traveling. I spend two years, from may 2000 to may 2002 in Eastern Europe, living in Russia and Belarus, and traveling to interesting places like Finland and Lithuania. What happened during those two years, while interesting, has very little to do with the history of Castalia, so we'll just fast forward ahead to August 2002. I had been home from Europe for a few months, and was working in a typically boring database application, when I suddenly found myself really wanting to be able to see what 'begin' goes with what 'end' in my code. Finally, I had an excuse to pull out that old OpenTools API knowledge and make something useful with it.
Thus began the first iteration of what became Castalia's Structural Highlighting. In its first incarnation, it was a keystroke you could press to jump to the nearest 'begin,' and from there to the corresponding 'end.' This was not very exciting, and although it worked well, it didn't quite do the job. I showed what I had created to a few colleagues, who offered various suggestions. One suggested that it would be nice if it could highlight the 'begin' and 'end' keywords like the parenthesis matching features of almost every other programmer's editor known to man.
I thought this was a fantastic idea, and the concept of actually drawing on Delphi's editor window intrigued me. After much trial and error, and a lot of learning about how the IDE works internally, I figured out how to do it, and the keystroke stopped jumping from 'begin' to 'end', and instead drew a line from one to the other. Here is the first screenshot ever taken of Castalia:
You'll notice that the popular Editor Line Numbers are already present. The line numbers were created as I learned about the internal structure of the IDE windows. On a whim, I wondered if I could insert a control into the editor window. I could! It was a suggestion from another colleague to put the line numbers in it, and the idea just stuck.
One thing that was discovered in the process of creating the Editor Line Numbers was that certain events could be uncovered to discover when the editor had changed, whether the text had changed, or just the view. This was used to keep the editor line numbers synchronized with the editor, but had important implications with the "begin-end matcher." The next step was getting rid of the hotkey. Still following the example of parenthesis matching editors, I wanted this highlighting line to appear whenever the cursor was in a 'begin' or 'end' keyword. Using the same techniques that allowed the editor line numbers to stay synchronized with the editor, this was accomplished without much difficulty.
Then one day a major paradigm shift occured. Someone suggested that if those lines could appear without having to specifically request them through a hotkey, why couldn't they just stay there all the time, continually indicating the structure of the code? I had been so stuck in the "parenthesis matching" rut that I hadn't even thought of this! I ended up rewriting the whole system, changing the name to "Structural Highlighting," and adding the ability to highlight every block in the file, not just the one where the cursor currently resides.
Using a parser to do structural highlighting for the whole file led to the navigation toolbar. This was something I always thought was missing from Delphi anyway, and since I had already written a tool that continually parses the code, it was a logical step to have it build a primitive symbol table. Having already done the editor line numbers, it was easy to add another control to the editor, this time a TToolBar, and put in some comboboxes. Other parts of the unit that were easy to parse (like the uses clause) were also included. The first editor toolbar didn't look very different than it does today:
Interesting side note: This screenshot was taken using the Delphi RichEdit example application as the code. To this day, that application is still used to show Castalia's features whenever possible.
Around this time, I decided that this project was turning into something that other people might want, and the project was named "Jacob's Ladder." Thus, all of the files in Castalia 1 were named Ladder*.bpl. The first installer was built and Jacob's Ladder was distributed to some friends and associates.
Comments and suggestions began pouring in, as well as a number of bug reports. For your entertainment, here are a few screenshots of early bugs in Jacob's Ladder:
As the suggestions began pouring in, new features were added. At some point, I realized that the parser that does the structural highlighting and navigation stuff could also be used as an acceptor. This was the birth of the squiggly red lines that became the Live Syntax Checking
By January of 2003, Jacob's ladder had developed a considerable number features, and was beginning to feel like something that people might actually buy. By mid-february, an official beta was released, and a price point of $50 was set and the name was changed to "Castalia,", with the goal of a mid-march release. As always happens with version 1 software, the release date came and went, and a new goal was set, trying to get it out the door the first week of april. On march 31, the last item was crossed off of the todo list. April fool's day seemed like a fun day to launch a product that would do things that people would have a hard time believing. And so, the afternoon of April 1, 2004, Castalia was released. You can see the original newsgroup post announcing Castalia here.
It took about an hour to get the first bug report. There was a conflict between Castalia's project statistics and advanced versions of TeeChart. It took about an hour to get that worked out and get a fix posted, and Castalia's reputation as a product with fast customer service began. Over the next few days, some 40 adventurous buyers plunked down $50 for Castalia Pro, without ever having tried it, as it hadn't occured to me that a demo version would be a good marketing tool.
Over time, Castalia improved little by little, and the business of selling Castalia improved leaps and bounds. By July, sales were strong and I had dedicated myself to Castalia full-time, leaving the boring database applications to the people to whom I was selling Castalia. As more and more comments came in, I began to really dislike the ad-hoc code base of Castalia, which was just a big mess of features all being held together by duct tape and string. After releasing Castalia 1.2, I set out to rewrite the whole thing from scratch, this time applying the development principles and techniques of a real commercial application, as opposed to the personal project that Castalia 1 really was.
(Technical aside: Castalia 1 was simply a bunch of new features all written in one big clump of code. It was messy and hard to maintain. Castalia 2 wasn't just written, it was designed, and makes fantastic use of the publish/subscribe pattern. It provides a number of extensions to the Delphi OpenTools API, some of which occur with the use of plain old code injection. All of the visibile features of Castalia are actually plugins to this core, which is a plugin to Delphi. All of this works together to provide a solution that's fast, elegant, and easy to maintain and update.)
Development of Castalia 2 began immediately, and I was so excited that I was in "death march" mode the whole time. By mid-december, I felt that Castalia 2 was ready to release. Throughout the development process, customers and friends were surveyed and usage patterns were studied. The goal was to create a real productivity tool, rather than a neat set of things that make Delphi that much cooler. All the research pointed to a price point of $179, which I personally felt was too high, and since I'm the boss, I decided that $99 was a good price. Given the relatively short time between Castalia 1 and Castalia 2, I also decided that the upgrade price would be $49, the exact difference between the original price and the new price. Most of those who bought Castalia 1 appear to think this was quite reasonable.
New Year's eve was an exciting party, as we rang in both 2004 and Castalia 2, launching Castalia 2 at just about 12:15 am on January 1, 2004. The first order came in at about 12:17 am, and we were off to the races, and we've been enjoying it since.
Editor's Note: This article was originally published on March 2, 2004. It has been edited for reproduction here.
