The Occasional Masthead

This quote from an article at the rather wonderful Apple Folklore site:

bq. Bill Gates and Steve Jobs were born in the same year and shared a similar vision for the potential of personal computers. Each one thought he was smarter than the other one, but Steve generally treated Bill as someone who was slightly inferior, especially in matters of taste and style. Bill looked down on Steve because he couldn’t actually program.

Doesn’t that sound like the next 20 years of personal computer culture clash?

Robyn bought me a copy of the video of Labyrinth. Isn’t that sweet? It’s easily one of my all-time absolute favourite movies. “Breakfast at Tiffany’s”, “Roman Holiday” and “Casablanca” are all up there as well, but Labyrinth is close to the top of the list.

I’ve always been fascninated by labyrinths, ever since I read Ursula le Guin’s “A Wizard of Earthsea” at a very young age - If I recall correctly I would have been about six. Of course, in retrospect, much of the book went over my head at the time, but I fell in love with labyrinths and mazes at that time.

This is probably one reason why I’ve always enjoyed the dungeon-crawl style of RPG computer games - ever since the original Wizardry on the Apple II, the ones that I’ve enjoyed the most have involved labyrinths of one sort or another.

Hmm. Perhaps this explains why I like programming: the creation of elaborate and labyrinthine mental constructs. Food for thought.

I’ve done 63.75 hours since Monday morning, mostly spent in VB 6.0 Hell. There are reasons why I’m writing what I’m writing in VB, but I wish I wasn’t. Still, my bosses are being very supportive, and I’m making progress. The problem is that so much of VB just simply does not work except for trivial cases, and I’m spending a lot of time churning out verbose, plug-ugly, brute-force-and-ignorance code.

At 7:47pm on Tuesday night, I had this to say

After 11:00 hours of banging my head against the wall, the only thing that I have achieved today is finding that (a) Microsoft’s help is horribly wrong in many key places, b) their website contradicts their online help, c) the DataGrid object is completely stuffed and doesn’t come close to working for anything other than completely trivial cases.

Next morning, I expanded on that. Here’s why not to use the DataGrid

Just to explain the previous a little more fully. The DataGrid object is supposed to be a magic control which you connect to a source of data that magically paints and manages a set of data from that source. A little more precisely, the DataGrid is associated with an ADO RecordSet, either directly, or via a DataEnvironment. There are several big problems with the control, which may stem from an apparent design whereby once a dataset has been associated with a DataGrid, then the only authoritive version of that dataset is the values cached in the control (more on that below). Some problems:

1) despite the documentation and the design interface which explicitly say you can display boolean values as checkboxes in the grid: you can’t. At all. Not possible.

2) If you attach a RecordSet that has a connection to a database, then changes on form immediately try to cascade through to the database, there is no way to save or cancel a set of updates for the entire RecordSet. This makes it useless for anything other than trivial or sloppy products, as you are not giving the user the option to back out of changes.

3) In order to get around the problem above, you can create a RecordSet and disconnect it from the database (through some magic, this will, after a fashion, allow batch updating when/if reconnected). The RecordSet can be created by hand, it can be obtained from a DataEnvironment, or it can be from a class that has the right bits of the RecordSet interface. Theoretically that means that you can create a “working” RecordSet, make the changes in it, then either cancel all those changes and discard the working set, or commit them. The problem is this: once you associate that RecordSet with the DataGrid control, the control is in some fashion caching the data internally: if you change the content of the RecordSet, you cannot cause the control to update itself with the new content. You can go the other way, but that misses the point. More horribly: you cannot flush that control-level cache. Even if you unload the form that the control is on, the data persists. The only way to flush it is to exit the application (which is a hell of a way of letting the user cancel her changes).

4) If you attach a RecordSet to the DataGrid, then use the RecordSet methods to do updates to the database, then the next time the DataGrid becomes active, your application will throw up because the DataGrid will decide it no longer knows how to tell if the data in the grid has been updated.

5) An associated problem that may be a feature of having an Access database underneath is that the RecordSet methods for testing whether a tuple in the recordset has changed/will change the database don’t seem to work at all (ie RecordSet.Status returns 0 irrespective of whether the tuple has been changed/inserted/deleted).

Simple guideline: DO NOT USE THE DATAGRID FOR ANYTHING SERIOUS.

I’ve got until Friday (which I’m interpreting as start-of-business Monday), to build and deliver a VisualBasic application. It’s nothing horribly complicated, in theory, just a browser/editor for a local Access database. However it’s been a long time since I’ve done anything in VisualBasic, and VB 6 bears little relationship to VB 3 and 4.

After having spent a few months working with JBuilder, all I can say about VisualBasic is this: it is horribly, disgustingly, vileley broken. If this is the tool that new programmers are raised on as children, it explains a lot about the parlous state of the programming universe.

There are two areas that are painfully broken: the language itself, the IDE, and the help. Make that three areas that are painfully broken: the language itself, the IDE, the help and the documentation. Make that four…

Somewhere in it’s ancestry VisualBasic counts the ANSI standard BASIC. But Microsoft have “improved” the language to the point of being unrecognisable. The syntax is wildly inconsistent, and legal constructs in one place are illegal in other apparently identical places. Why, in the name of the gods, are there three different, not-quite-consistent, ways of assigning an expression to an lvalue?

THING = EXPRESSION
LET THING = EXPRESSION
SET THING = EXPRESSON

Why build a Collection object that has ADD and RETRIEVE methods, but no way of testing for the existence of something in the collection other than “try to add it and trap the error if it’s already there”?

The IDE is horribly bad. The editor sometimes auto-indents, sometimes doesn’t. It sometimes spots syntax errors, and sometimes doesn’t. It will magically disperse changes to upper/lower case letters in identifiers, but not changes to the identifier itself (ie it will globally change tHis to This on request, but not tHis to That). The “wizards” build code that is incomplete and buggy. The debugger struggles to trace anything complex.

Error messages are usually maddeningly vague, and sometimes horribly misleading — would you think to recognise that a “SET” keyword was missing when given a message that a “Parameter is not optional”?

The documentation is just as maddening. Quite apart from the fact that Microsoft have expunged virtually all materials from their websites other than those that apply to .Net, the supplied documentation is horrible to navigate. Mostly it’s exposed through the “help” application, but often navigation goes through modal pop-up pick lists which break the “back” and “forward” navigation.

I expect to have gone quietly mad by the end of the week.

Robyn and I went to the beach yesterday. I sat there for several hours reading a VisualBasic text book (don’t ask) with my shirt off, then went for a nice walk with Robyn.

I now resemble a cooked prawn. It’s been about twenty years since I got really sunburnt, and now I remember why (ouch) I it’s been (ouch) twenty (ouch) years.

I keep assuring Robyn that it will pass, and she keeps assuring me I’ll get a good tan. Meanwhile: ouch.