Delphi VCL wisdom

I thought it might be fun as I wind down my last week at CodeGear to post a few $l(Baz Luhrmann)-esque lists on various Delphi product areas. So here’s the first list relating to VCL:

  • Learn to use Actions then, learn to write action descendents
  • Learn how to create controls dynamically
  • Learn the difference/relationship between Parent and Owner
  • Learn how to handle a Windows messages
  • Learn how to use the OnCreateXXX methods in ComCtrls.pas
  • Use TCustomTreeView.ChangeDelay
  • Use TTreeNode.Data, TListItem.Data, TStringList.Objects
  • Learn how to use TMenuItems dynamically
  • Use Visual Form Inheritance
  • Use a custom icon for your application
  • Learn TScreen, TMonitor, TMouse, TClipboard
  • Use TApplicationEvents
  • Learn to use Align = alCustom
  • Learn when to override CreateParams
  • Learn when to use DoubleBuffered
  • Use frames
  • Learn to use packages

So, perhaps this can spread this through the Delphi blogsphere. If your a Delphi blogger let’s see your list.

6 thoughts on “Delphi VCL wisdom

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

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

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

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

Comments are closed.