JM>> First method I enter the name of my subroutine in the OI
JM>> ShowForm event field.
JM>> Second method double click on the OI ShowForm field and it will
JM>> create the shell of a subroutine TForm1.ShowForm, and you can
JM>> enter the call to your subroutine there.
GW> These do the same thing. The second method merely allows you to name
GW> the event handler yourself instead of using the default name.
They accomplish the same thing in the final result, but they do
not do the same thing. The 2nd one makes a small subroutine in
the soure file and puts an explicit call to your subroutine in
that subroutine. The first method doesn't do that.
GW> If the code is small and relates directly to UI control, I put it in
GW> the event handler. If the code is larger or is more related to
GW> application, business, or data logic, I put it in a separate routine
GW> and call it from the event handler.
That's along the lines of what I was saying. For a large app,
it seems more appropriate to call it as you said. Which gets
back to my original point.
GW> Of course, you can always assign the event handlers yourself in the
GW> FormCreate event handler:
GW> Button1.OnClick := Button1Click;
GW> Edit1.OnChange := Edit1Change;
GW> But why spend the time and effort to do this? It's much faster and
GW> easier to manage from the Object Inspector.
It is faster and easier initially, but what about trying to
modify or debug it a year later? I don't know - I haven't
gotten that far in Delphi yet. However, it seems to me that it
is going to be hard to follow the flow of the program wqay down
the line. For instance, there are 4 things done to a form
Create, Show, Paint, and another one I can't think of right now.
Neither can I remember the exact order in which they are done.
And none of that is written explicitly into the source code from
the OI, AFAIK.
Jud McCranie
* Silver Xpress V4.3 SW20178
--- PCBoard (R) v15.3/M 5
---------------
* Origin: Riverdale, Ga (1:133/9024)
|