Delphi COM Programming [Paperback]

A good teacher must know how to teach, and a good writer of technical literature must also know how to put things across in a measured, structured and empathic way...

Mr Harman falls short here.

There is no CD that comes with the book; not even a floppy: sourcecode is available on the net, although it's not where the text says it is... That being the case (and since the sourcecode is not available on CD or floppy) one might think that Mr Harman would choose short, punchy examples... -he does not. The example code listings tend not only to be overlong, but frequently one finds oneself having to get to grips with aspects of coding not directly relevant to the discussion in hand. For instance, one finds Mr Harman complicating his introduction to 'interfaces' with code relating to 'polymorphism', complicating his first proper COM listing with code relating to 'bin-packing' algorithms, complicating his discussion of type libraries with the code for a fairly big and complicated program to READ type libraries that is really not appropriate to an introduction, and so on (consistently). This, it has to be said, is not evidence of a good pedagogical style. It is not even evidence of the kind of basic empathy for the reader that IS a prerequisite on the part of a good technical writer.

Let's say that as a reader new to COM, you were still not 100% clear about the meanings of one or more of these words: 'object', 'interface' and 'reference'. Would you then be able to make sense of the following, when the terms have not yet been succinctly defined in the text?

'In the examples presented so far, I've been showing you both object references and interface references as if they work together and are interchangeable. That is not the case. The interface model is an alternative to the reference model. When implementing one or more interfaces in a class, you should manipulate objects of the class using only interfaces. This section shows you how you can get into trouble by mixing the object model and the reference model'.

In Chaper 4, on the subject of 'Automation' it seems that Mr Harman has changed tack a little and decided to provide a more concrete (and simple) Delphi example more geared toward the steps one should take in the Delphi IDE to code the example. Fine! But then we find a number of inconsistencies: in Delphi 5 the compiler complains about the 'double' type returned from an automation server object, that we have been asked to specify. OK a little fiddling (if you know how to fiddle it) will get around this one. The next problem one comes across is less insignificant, however: half way through his automation server example Mr Harman changes Class names- one minute he is talking about an IAreaUnitConverter class, and the next he refers to an IUnitArea class (both of which are in fact the same). Clearly he has not checked his code properly, and as a result the reader can only become (more) confused.

Did Rhuver Barengi, Derek Benner, or Xavier Pacheco (the 'technical reviewers') actually read this book, and try the examples for themselves? If so then they are being remarkably slack in giving the thumbs-up so easily to material that so clearly falls short from a pedagogic point of view.

It is important, in the effective communication of complex ideas, to be able to succinctly stress those points that are most significant, so that the reader can begin to build up a framework, or model, into which subsequent information can be slotted. Mr Harman is not good at this: for example, under the subtitle DispInterfaces his first sentence is 'Somewhere between interfaces and variants are dispinterfaces'. Very clear. Does it become clearer? No: the next sentence reads 'A dispinterface declaration looks almost identical to an interface declaration except it uses the keyword dispinterface instead of interface'... So does he go on to describe the purpose of a dispinterface, then? No, not at all, or only very obliquely. He refers to variants here, but has he defined or clearly described variant types prior to this point (basic rule of teaching: introduce concepts clearly and then use them later as foundations upon which to construct a more complex framework). The answer is 'no, he hasn't' -previously, variants have been touched on in the same 'if you know this already then fine but if you don't know it already don't expect a clear and simple explanation here' style. This is frustrating for those people that the book, is ostensibly at least, aimed at.

At risk of labouring the point, here is how Mr Harman introduces the reader to Delphi's ActiveForms. After two short sentences describing what ActiveForms are, in one page of text we are led through using the ActiveForm wizard to create a new ActiveForm. The next fourteen pages consist of code listings which are the output of the wizard, including a grand total of some ten lines of the author's own code. None of this code is commented. None of it is explained properly in the surrounding text. The chapter ends with a few short paragraphs on how to test your ActiveForm. This is not good enough.

Is this a book written for Delphi programmers who are new to COM, or is it a book for people who already have a grounding in COM but who are new to Delphi? Mr Harman suggests the former: I would suggest that the latter is actually closer to the mark...

A good introduction to COM?

Could do (quite a bit) better.

Code listings are always a good idea but including the complete pascal translation of a type library (yes, that's with all the delphi generated comments) and other delphi generated PAS files for most of the examples is just silly. Perhaps a few pages discussing IDL/MIDL and then using IDL for the description of type libraries would have been a more efficient use of paper.

Here's one example, in the description of active forms there is a one page description of using the wizard and then 15 pages of listings, ALL of which have been delphi generated! And just two pages before we've got another 17 pages of generated code, this time from the conversion of a VCL control to an ActiveX one.

In general, most examples just list the full code and don't really highlight the interestng bits.

Another thing I noticed, deep into the book we get the useful comment '...a unique CLSID (which is simply a GUID) ...'. CLSIDs have been discussed three chapters earlier so we already know this and I think this reveals that the book is really just a collection of examples and not a progression of COM concepts, each building on the last.