Delphi VCL wisdom

6/26/2007 1:03:50 PM #

Very good list - documentation and *paper* manuals should cover some of those topics really better ;) Also some features (i.e. VFI, frames, packages) could be improved.

I'd add:
- Use TStream and its descendants
- Learn to use TReader and TWriter
- Learn to use RTTI
- Leart to use TThread and the synchroinization objects/functions
- Learn the many functions the VCL RTL offers, just to avoid to reimplement them
- And last but not least - learn to respect the OS guidelines.

Luigi D. Sandon

6/26/2007 2:37:26 PM #

Luigi,
Hang tight more lists are coming including one for the RTL like your items.

Steve Trefethen

6/26/2007 2:46:26 PM #

I would also add
- Learn XML and XMLDocument and associated classes
- Learn to use exception handling and how to retry actions when appropriate
- Learn TCollection and how to sort a collection
- Get a decent memory profiler and learn how to catch memory leaks.

Chris Miller

6/26/2007 9:24:17 PM #

dcleggsblog.blogspot.com/.../...rite-software.html">dcleggsblog.blogspot.com/.../...rite-software.html

David Clegg

6/27/2007 11:24:00 AM #

Ah, but I always thought the VCL encompasses its RTL too... or it was CLX or whatever??? ;)

Good lists, anyway, now we're hiring new developers, I'll print them and hang them around

Luigi D. Sandon

6/30/2007 3:58:31 PM #

> Use Visual Form Inheritance

Oh, God, no. That stuff is so horribly broken.

It is far too easy to be looking at the descendant form/frame, not meaning to modify anything, and to accidentally change a property, or a control's position, or whatever -- and suddenly you're not inheriting any changes made on the base anymore. There's no way to tell whether a change will actually work on the descendants without manually reading the DFMs of all the descendants (if you can figure out which ones they are), and there's no way to fix it without manually hacking the DFM.

Now, if Delphi did Visual Form Inheritance the way WinForms does -- i.e., making use of this revolutionary "object-oriented" idea called "encapsulation", making the controls actually be part of the base frame, and not allowing them to be changed except in ways you expect, via properties you expose for that purpose -- then VFI might be usable. (But not really, because you need your own published properties to expose the stuff you actually want to be editable, and with Delphi that requires packages.)

And that still wouldn't take care of all the IDE limitations with editing one form while its ancestors/descendants are/aren't open in the designer, and all the error messages you get when you open a descendant whose ancestor isn't currently open and hasn't been explicitly added to the project file, and...

As the feature stands, we've learned to stay far away from it, and to get rid of it in our existing code (written before we knew better) whenever we can. We create our frames in code at run-time. That way, our program actually works when we change things.

Joe White