The Perpetual Newbie Journal Entry #3.1
This article first appeared on http://www.undu.com
Code reuse. The mantra of all Delphi programmers of whatever experience level. Don't re-invent the wheel. Buy this third-party component or that library and program happily every after. And if you can't or won't buy it, build your own.
And so I did. My first component was a simple TLabel descendent that came transparent and set to Arial Bold from the beginning. A simple component and a great time-saver. In addition to TLblArialB, I also created a TLblTimesB along the same lines. I use them all the time.
With experience comes ambition. I wanted to create compound components. In particular, I wanted an Input box variant that would be number-specific. I wanted the dialog to have a variable caption and prompt property, a minimum and a maximum for the spinner and I wanted asInteger and asString style properties. Dipping into books by both Ray Konopka and Marco Cantu, I was able to get a version of the component up and running. But like many of us, my ambition had exceeded my abilities.
There were troubling signs. The first time I ran the component in a test program, the dialog box came up with the expected selection of the numeric entry field. But the second time, the OK button was the selected control and the third time it was the Cancel button. Obviously, I was either leaking memory or not destroying my little object correctly. I just couldn't trust the component in real life. I picked at the TInputDlgInt code occasionally over the next few weeks.
But then a casual re-read of Cantu's book gave me cause to slap my forehead and shout 'Eureka!' While not as elegant, I had a time and cost effective alternative to developing the dialog by just stealing from my OWN code with a component template. And the creation couldn't be any easier. I called up one of my prior programs with a working hand-cobbled version of the dialog. I selected ALL the items on the form and then went to COMPONENTS|CREATE COMPONENT TEMPLATE on the menu. I accepted the default location on the palette of Templates and changed the icon to a bitmap I had designed for my precious TInputDlgInt component. I changed the default name of TLabelTemplate to TInputIntTemplate and hit OK. My creative wizardry requirements were at an end.
In my current project, I created a new form named FInputDlgInt to call from the main form. I went to the template palette and dragged the brand new TInputIntTemplate to the form and it instantly filled the form with ALL of my carefully created objects. I could have changed the text to whatever I was going to use in that specific program, but I left everything unchanged.
In my main program, I created a code insight template that I called IdlgI. It was:
FInputDlgInt := TFInputDlgInt.create(nil);
with FInputDlgInt do begin
caption := '|';
LblPrompt.caption := '';
eInput.Minimum := 0;
eInput.Maximum := 0;
// Save any values needed here
Having saved the form into a common library folder rather than the application folder. I now have the closest thing to a component I can want, without much effort. Sure I'd like to solve the flaws in my own component. And I will, in time. But in the meantime, I have working code reuse. And that's a time and money-maker.
It should be noted that the use of a common library form placed in a central location is an example of code-reuse without the necessity of creating a component or even a template. That's because this example was a self-sufficient dialog. However, having the template available allows me to create the same effect on a panel in a form. And for other compound creations, such as a button bar with associated dialogs for performing a variety of tasks, the component template is a quick way to get most of the grunt work done, without worrying about having all the bits and pieces refined to whatever your programming style requires.
Idea Mechanic Inc
Bramalea ON Canada