Sorry I’ve been so quiet here of late. I’m in the US for planning around future releases, and that has kept me pretty busy. Also, jetlag always hits me badly on US trips. Fortunately this time round I’ve had food poisoning as well, so at least that’s given me something to do from 1am to 7am.

When all else fails, post a photo…

I’ve been doing some exploration around migration issues from Delphi 7 (Win32) to Delphi 8 (.NET). Yes, VCL for .NET covers a whole bunch of stuff and makes migration a whole bunch easier than it is for other languages, but there are still things you can do in Delphi 7 code that won’t migrate seamlessly to Delphi 8.

Today, I sat down to look at moving a COM client from Delphi 7 to Delphi 8. I started with a nice, simple scenario. A COM object called BasicSrv, which exposes an Add method. Add takes 2 parameters, x and y, both integers and returns another integer. Hardly staggering stuff, but ever since I started using DCE years ago, through DCOM, CORBA, COM+, J2EE, whatever, this simple scenario has been my "Hello World".

Once I had this COM object in Delphi 7, I created a Delphi 7 client. Again, very simple. Two edit boxes, a button and a label. Click the button, we create an instance of the COM object and call Add, shoving the results back into the label. The code looks like this:

implementation

uses Server_TLB;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  basicSrv : IBasicSrv;
begin
  basicSrv := CoBasicSrv.Create;
  Label1.Caption := IntToStr(basicSrv.Add(StrToInt(Edit1.Text),
StrToInt(Edit2.Text)));
end;

Like I said, nice and simple.

So then I went to get the client working in Delphi 8 under .NET. I’m a little ashamed to admit, I didn’t expect the experience to be very pleasant, as it seemed like way too much "stuff" had changed under me in the move from Win32 to .NET for this to be anything but painful. Anyway, I opened the Delphi 7 project in Delphi 8, removed the Server_TLB unit from my project and added a reference to my COM object. Surprisingly, the code needed to call this COM object from .NET looked like this (the bits that changed are in bold):

implementation

uses Server;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  basicSrv : IBasicSrv;
begin
  basicSrv := BasicSrvClass.Create;
  Label1.Caption := IntToStr(basicSrv.Add(StrToInt(Edit1.Text),
StrToInt(Edit2.Text)));
end;

All that changed was my unit name and the class name. And I suspect that if I paid a little more attention while adding my reference (or used tlbimp directly), I may have got away with no code changes. How cool is that?

I’ll be spending a bit more time with examples that are a little more complicated, but I’m really encouraged, and a little ashamed of myself for doubting 🙂

I’ve been enjoying Pat Helland’s blog a lot lately, especially the discussions that are popping up in his comments section. The discussion about SOA reminds me a lot of a few years ago when I spent most of my time doing training and consulting around WebMethods’ EAI product.

I didn’t always succeed, but what I tried to get across to people in those training courses was that the single most important thing they were designing in their solutions were the documents being passed around. Obviously, the processes were required as well, but the most painful failures I saw in EAI solutions on client sites came back to poor document design, not poor business logic implementation.

This focus on documents is a lot harder for most developers than you would think. You’ve heard the saying that goes something like "when the only tool you have is a hammer, the whole world looks like a nail"? I think sometimes OO becomes our hammer, I’ve certainly been guilty of this. I can remember a number of students complaining early in the course that this focus on documents went against everything they knew about OO design, however I can also remember a number of those same students having a lightbulb moment a day or two later. Interestingly, I ran a course for a bunch of non-developers, which I initially dreaded (C’mon, the course was called something like "EAI for Developers"). However, on the whole they seemed much more comfortable giving the documents the highest priority, and that course was one of the most enjoyable in terms of students "getting it"

For mine, this comment from John Cavnar-Johnson is dead on the money:

It’s not enough to have orchestrations, messages, contract, schema, and policy. We need to be able to define business documents that exist separately from the services that exchange them (something that is hard to do today with VS.NET and WSDL). These business documents need to have a conceptual identity separate from the schema that services apply (the schema for a purchase order being submitted for fulfillment is different than the schema for that same PO when it reaches billing). We shouldn’t be burying our knowledge of the actions that a service performs in the name of a web method call or SOAP header. We need to recognize that the authoritative record of the business data has to be in these documents, not in the relational store. The data type of a business element is a minor facet of its meaning, not the very essence of its existence.

Actually, there was a lot of good stuff in John’s comment. Definitely subscribed.

Oh, Pat has also shown up over on Channel 9, with a refreshingly pragmatic discussion about SOA.

© 2004, Malcolm Groves

I think I’ve gushed embarrassingly on this blog before about my admiration for Julian Bucknall. One of the things I always enjoyed about his articles in the Delphi Magazine is that he does a very good job of taking you through the workings of an algorithm without it becoming boring.

In his recent post about the need for a better grounding in Computer Science amongst developers, he points out some sites that do this visually, using Java applets (Java Models and Exact String Matching). Very cool. If only I’d had Julian or these sites available when I was doing my CS degree.

Oh, also just noticed that he mentions he’s back writing for The Delphi Magazine 🙂

After my Inspect Exception Object post yesterday, this morning I noticed a post over on FasterBetter.NET pointing out a comparison of Visual Studio.NET and C#Builder.

In a previous post I mentioned that I was using an unsupported tool from Microsoft called the Virtual CD-ROM Control Panel for WinXP. Well, I think I’ve just discovered why it is unsupported. I’m using it to run an install direct from an ISO, and the install is complaining about a missing file. However, if I burn the ISO to CD, the file is there.

Thankfully, someone just pointed me at Daemon Tools, which is also free but works just fine with the ISO that caused the other one to fail.

I’ve been doing some work in another .NET tool, which shall remain nameless for what it’s worth :-), and I’ve found myself missing a few features from C#Builder and Delphi 8. I don’t want to start a "My tool’s better than your tool" war, but I guess it’s not until you use another tool that you notice some of the features of the tool you’re used to.

Case in point: Exceptions. When an exception occurs during debugging, this other tool gives me a modal dialog with the details of the exception, but being modal, I have to dismiss it before I can go looking for my error. Problem is, my memory sucks. So, once I’ve dimissed this modal dialog, I invariably forget some of the details. I believe there is a magic string I can enter into the watch window to get the details of the exception, but I don’t think it’s documented and buggered if I can remember what it is.

C#Builder and Delphi 8, on the other hand, give me the same modal dialog, but notice in the screenshot above, the checkbox in the bottom right corner that says Inspect Exception Object? If I leave that checked, I get a Debug Inspector showing all the details of the Exception object that I can dock against my code while I go looking for my error.

A little thing maybe, but a little thing that I didn’t really notice until it wasn’t there.

Bill Hill, the co-inventor of ClearType and the head of the typography team at Microsoft, has a couple of short video interviews up on Channel 9. The one on Windows not being the most important OS made me smile (It might have something to do with the fact that he sounds a bit like my grandmother). Channel 9 so far has been a bit hit and miss, but it’s only the first day I think, so too early to unsubscribe from their feed.

© 2004, Malcolm Groves