Case Study 8 - REALbasic 2006 release 2

REALbasic is a cross-platform language, framework and development environment for Macintosh, Windows and Linux. I have used an old version for years to develop my Macintosh and Windows software, at a significant cost to my sanity. The system has always had promise and would be a phenomenon if it ever lived up to its own expectations. Unfortunately, it has always been very poor on features and heavy on bugs—the Win32 runtime in particular—which shows in my own work no matter how many months I wasted trying to work around them.

REAL Software’s solution to all the missing and mis-implemented features was to write REALbasic 6 in REALbasic. This forced them to add all the missing, necessary features that are necessary in any graphical framework, such as workable drag and drop. The obvious result was that the IDE became as slow, unstable and unreliable as all other software written with the framework. The minimum specification of machine needed to support the version 6 IDE itself is a 1 GHz Pentium chip; Visual Studio Express 2005, which is many times more complex, runs happily on a Pentium II 333, even if it is also full of bugs. I was running the Macintosh version on a 400 MHz iMac and it was bordering on unusable.

it was not very long before I realised that writing a tabbed, paned environment in REALbasic is hard, given that when I maximised the window, I was left with a stray scroll bar atop a list box:

With a development environment this bad, it hardly encourages one to hope for success with it:

I have no idea what the above pop-up menu during compilation is for, or why it is enabled and yet contains no menu items (no actual menu appears when you click the control).

One beef of mine with the old REALbasic is that you cannot subclass windows (or for that matter, change many aspects of them at runtime), but REALbasic 2005 upwards implements a Container class. Now, with this to hand, you can tell a Window subclass (any window) to subclass a Container, which seems absurd. After that, the Super (parent class) combo box in the properties palette for your Window subclass contains only “Container” and “<None>”. That is, it is now impossible to use the interface to select the original subclass of “Window”. Because it isn’t there. Don’t forget that REALbasic works off proprietary binary files instead of plain text files; the graphical interface is all you’ve got.

If you select “<None>”, you get the following delightful message on compile:

Excellent. The more peculiar part is that once you’ve cleared the Super property, you can then go on to select anything you like, such as make your window class inherit a runtime exception:

Or a quaternion. Or a push button… The opportunities are endless. As they should be, as this version is substantially newer and should be appropriately feature-packed. I am glad that custom listbox sorts are now permitted, and container controls—assuming they work (and the program is too slow for me to care to try)—are a fantastic idea. But how about one of my pet peeves, poor edit box support? Select All is now implemented, so no need to write a subclass just for that any more. Well, except that you can Select Nothing, too:

Undo is still not supported in edit boxes, naturally; you are just given a dummy menu item to taunt you:

In 3.5.2, this is desperate because text drag and drop is not recorded in any useful way in the event model, making it next to impossible if not outright impossible to undo text after a drag. I don’t know whether they ever sorted that out, but I see that you still have to collect and store styled text fragments by analysing the style character by character (it even tells you this in the manual) which is a primitive way to preserve text for undo and redo.

Even the online help scares me: what is with all the random characters in search results?

Or the lack of styling on subheadings?

Maybe I am being really fussy, but I would love to see more of an effort gone to for the authenticity of the look of the simulated menu items:

It’s no big deal but it would look more natural and not like a cowboy job. (Incidentally why does it use homebrew tabs instead of native controls?) I also wonder about this:

If you go by the vicious anti-9 feelings I have suffered over the years, File > Quit is dead, but REAL want to make their interface more confusing by giving you an empty Application menu that you can see but not do anything to!

Now suppose I don’t want to write for Windows or Linux. Supposing I have no idea where it goes in Windows or Linux? I am on a Macintosh, I want to to be Macintoshy. I thought that was the point of programming Macintosh software on a Macintosh?