Case Study 8 - REALbasic 2006 release 2
Friends and regulars of my site will know that I write my Macintosh and Windows software in the astonishigly archaic and hopelessly buggy REALbasic 3.5.2, dating back to 2001. The realistic feature count in REALbasic was always very low, so REAL Software came up with the solution: write REALbasic 6 in REALbasic. This forced them to add all the missing, necessary features of any decent graphical framework, such as decent drag and drop support. One would have expected them to have done a reasonable job of the whole compiling-REALbasic-in-REALbasic malarkey when it this new version was released, as REALbasic 2005. At the time of writing, we’ve reached REALbasic 2006 release 2, and thus it should be squeaky clean, right?
It’s no secret that my own software suffers from my use of an antiquated IDE, particularly in Windows builds, so I finally decided to play about with the latest version. And when they said it needs a 1 GHz Pentium chip to run the Windows version, they were not joking. I e-mailed them to ask what this was about ages ago (as I run a 333 MHz box), and they refused to reply. Now I know: REALbasic 2006 is pretty slow. I’m actually using the faster 400 MHz Tiger iMac for the tests and, well, it’s slow even on that, and we’re talking about a Pentium 500 equivalent or more? And I mean, the interface crawls, and surely all it has to do is manage a few tabs.
And 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:
The general quality of the package gives me the creeps; if the folk who designed it can’t get it to work, are we supposed to do better in our own projects?
And no, 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 old REALbasic is that you cannot subclass windows (or for that matter, change many aspects of them at runtime), but REALbasic 2005 upwards implement a Container class, an idea I had independently of REAL Software and was a popular suggestion it seems. 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 like standard IDEs; 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 IDE is too slow for me to care to try) – are a fantastic idea. (Mine! Well, and lots of other people too as I understand.) 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, it seems:
Undo is still not supported in edit boxes, naturally:
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?
I think this is where I got bored with REALbasic. It’s simply too slow, and I am too scared to write software using it. REALbasic 2006 can open my old 3.5.2 source (attempting to do which in REALbasic 2005 would just cause a crash) but when I attempt to compile HTTP Werkzeug, it complains that File > Close does not exist. If I had the patience I’d figure out all the things that need fixing (such as where it thinks File > Close has got to), but I don’t. It certainly feels a waste of money to buy a brand new Mac just to feed the insatiable greed of such slow software.