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...

To float or not.. redux..

The comments on my last post were all very good. There's a few, however, I figured I'd address with another entry since some folks don't nessesarily read the comments.

What I always wanted to know, but were afraid to ask: Why is the default Form position poDesigned and not poDefault?

This will take a bit of a history lesson. When we were designing Delphi (back in, oh, 1993), we had already chosen the "floating" designer as the design-time model. We had a specific design goal for the user experience that when they hit the "run" button, it simply felt like the application simply "switched" from design-mode to run mode. We used the high-speed compilation to our advantage. By defaulting to poDesigned, the application would simply have the appearance of simply "turning-on" since it didn't appear to physically move on the screen. There was a lot of internal debate on this very topic, but frankly, the product demoed *very* well with the poDesigned. In fact sometimes it was actually difficult to convince folks that we had actually compiled the application and that there is now a stand-alone .EXE on disk.

As Marc has written the argument of the out of screen forms is so simple to fix without an embedded form designer as I can't even believe you count that as an argument for the embedded designer

Sure. However, one thing you have to remember is that a design-form is a live instance of a VCL form. So, when you set the Left/Top properties, the form will physically move on the screen, and the module is marked as modified. We go to tremendous lengths to not modify any file as a side-effect of opening it in the IDE. Of course there are potential solutions, but few are minimal, or non-invasive.

a) A somewhat wider right text margin, (I keep worrying that I'm missing nonwrapping text)

b) Scalable text size...

Thanks for the feedback on the look of the blog. I'll still be tweaking it as I can get to it.

To float to not to float...

In other words, embedded designers or stand-alone top-level designers. This argument has certainly served to polarize the Delphi community more than anything else has in recent years. There are those that only accept a "pure" traditional Delphi style designer, there are those that don't seem to care one way or another, and then those that are perfectly fine and somewhat prefer an embedded designer. It seems, however that the Delphi "purists" are the most vocal and vehemently against what they would characterize as "messing with success," by adopting a modal/embedded approach to form design. Personally, I've adapted to using either style and can see some of the advantages that each side has to offer. You might come to the conclusion that since I'm the one that did all the work to embed the VCL designer, I have a vested interest in keeping the designers as purely embedded. This certainly would allow me to focus on making that one mode work the best that it can. However, there are a few items that the embedded designer simply isn't able to address.

The embedded designer makes for a cleaner, more controlled environment. You always know where the designers are located, you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen. The designer also can display the border style of the form in the actual style that it will end up being rendered as. And, there is just a feeling that everything is more organized and more "under-control" with the embedded designer. There isn't this haphazard arrangment of windows with all your other applications peeking at you from between the cracks.

In the other camp, there are some things that the top-level "floating" designer does that simply cannot be done as easily with the embedded designer (and by extension, a single-window docked IDE). You can design a form that is at or near the actual screen resolution much easier since there is no "frame-overhead" for each designer. You can arrange the forms in such a manner that you can see several at once, which in the case of inherited VCL forms, is very helpful when modifying an ancestor form so you can see the live-updates on all the descendants and determine if moving the "OK" button will obscure something on any of the descendants. While, personally I prefer to dynamically position the forms at run-time, you can set the form position to "poDesigned" and manually arrange all your forms in the locations in which you want them to appear at run-time. Then there are the issues regarding the more frequent use of multi-monitor systems where developers will use the primary display to position the design-time forms, and use the secondary display for the menus, code-editor, OI, and other design-time/editing support windows.

Now before you start warming up your flamethrowers and start indiscriminately spewing expletives regarding your disdain for one style or another, just understand, that this issue has been heard loud and clear and we are looking into ways to address the issue for a future Delphi product release.

New Skin...

OK... I finally spent a few moments and created a new .Text skin (that probably works only in Internet Explorer... :-) that resembles the skin I use on my original blog site. It's not perfect, but it at least has most of the elements I wanted. Did I mention that CSS w/ HTML is about as enjoyable as slamming my hand in a car door?

Welcome...

Welcome to my new home on the web. From now on I'll be posting to this server which is officially hosted by Borland. However, please be aware that the same disclaimer still applies. Any views expressed here are my own and not those of my employer, Borland Software Corp. As soon as you begin to think that my views are a direct reflection on Borland, then please seek professional help immediately for the condition known as lackofhumoritis.

Anders Hejlsberg still evokes all manners of awe..

Chris Sells' post, My First Presentation For A Distinguished Engineer, underscores the level of respect and awe that Anders Hejlsberg still commands as a Distinguished Engineer at Microsoft. It is just interesting when other folks seem to be thoroughly enthralled and "star-struck" about the fact that Anders requested a technical briefing. I worked very closely with Anders during the early days of Delphi (and TPW 1.5 and Borland Pascal 7.0), and I must say that he is certainly a very charismatic and approachable person. He has an uncanny knack of being able to tell you when an idea was complete bovine scatology, yet your ego and self esteem remained completely intact. In fact, while Danny and I were at the Windows 64-bit briefings back in March, Anders had specifically requested that we try and meet for lunch. Unfortunately, he is also a very busy man and we were unable to connect. Anders is certainly deserving of all the accolades he receives.