Delphi Basics..

Sometimes perusing through the public newsgroups will reveal some real gems among the rough.  Take for instance, there is current a very civilized and informative discussion currently taking place in borland.public.delphi.non-technical regarding different ways to make it easier for the Visual Basic programmer to move to Delphi.  One such thing that came up was this web site, http://www.delphibasics.co.uk/.  If you're looking to start programming in Delphi, this is a fantastic starting point.

I am not Danny, nor is Danny, I

Danny has found an interesting link to a bit of satire regarding the “pollution” of the Pascal language by Borland and Delphi.  However, once again, this blog post has mentioned this blog, yet the link is to Delphi Compiler Core.  Of course Danny recognized this and even mentioned it in his post.  So I just can't let this one go by without a comment.. ;-)

Mark Edington is now blogging

Well it looks like another cohort in crime has come out of the woodwork to place their mark on the blogging world. Mark Edington is now up and running with this whole blogging thing. Mark is another one of the "old-timers" on the team. He's been around since before the initial development of Delphi. Welcome aboard Mark!

Message methods in Delphi for .NET

Just got bit by this little oddity in how Delphi for .NET handles message methods. What is wrong with the following because it will compile?

TBaseClass = class(TWinControl)
procedure WMLButtonDown(var Message: TWMLButtonDown); message WM_LBUTTONDOWN;
end;

TNewClass = class(TBaseClass)
procedure WMLButtonDown(var Message: TMessage); message WM_LBUTTONDOWN;
end;

...

procedure TBaseClass.WMLButtonDown(var Message: TWMLButtonDown);
begin
inherited;
{ special processing here }
end;

procedure TNewClass.WMLButtonDown(var Message: TWMLButtonDown);
begin
inherited;
{ more special procesing here }
end;

It seems that the compiler will generate a raw call to the inherited method when it sees the "inherited" keyword without doing anything with the paramter. The ancestor's message handler will now treat the TMessage parameter as if it were a TWMLButtonDown message cracker. This wreaks havoc on the .NET runtime, but not in the way one would expect. One would possibly expect exceptions like invalid casts. However there is actually no telling what might happen. It actually react just as randomly as if you'd taken a random Integer value and cast it to an object reference then proceeded to call methods or dereference it. Now, of course the above code doesn't pass PEVerify, and had I actually thought to do that I would have seen the problem. So for all you component developers out there moving your Delphi components to Delphi 8 for .NET, just keep this in mind. You should declare your descendant message methods to match the ancestor's declaration (even though it is not required in Delphi for Win32). Yes, Danny and I are going to be working on some solutions to this delima for a future Delphi for .NET release.

Busy days...

You have probably noticed that there has been a drop in the flow of posts. There are several reasons for this. Most noteably is the fact that there isn't too much new information at this point that I can talk about. Then there is the fact that we're currently in the midst of approaching some internal milestones and much of my focus has to be on meeting those goals. No, I can't tell you what the milestones are and what their for... Sorry. As soon as I have some new juicy bits of information, tips or tricks, I'll try and get them posted here. For now, however, there will be a dearth of posts...