Alan,
You're not alone. I still have to fight against doing things within
event handlers like this all the time! Doing so is easy and obvious, and as
long as it works, and you don't need to worry about others having to look at
or modify your code, it's probably okay you tell yourself. What finally
broke me from this bad habit was as I started working with databases.
Ensuring that my interface code and that with which I add, edit, and read
the database with is separate and stand-alone made it possible for me to
re-use a lot more code, and switch between different databases and formats
without having to re-write an entire application! Once I got used to
working that way, it became easier.
In your example, where you need to create a collection of objects
and these objects have their properties set via the values entered into a
stringgrid, there's really not much of a difference between it and how you
setup and operate on dB tables. To make things like this easier to work
with, I usually set up a separate unit in which I define an object and the
methods that allow me to create, set, edit, delete and free the objects and
their properties. I set up functions which I call from the event code of
the stringgrid, passing the values back to my class which does all the work
to the object. So even if later I build a different interface using edits
instead of a stringgrid, the interface is ALL I have to change!
As a rule of thumb, I consider any methods that are to operate on an
object/class to be an integral part of that object/class, including those
that read and write property values. But if you're having trouble
understanding how to create objects/classes the best thing you can do is
copy some basic ones from within Delphi itself, like a TObject, a TForm, or
a TCollection, and use them as a starting template for creating your own.
I've learned more from just diving into Delphi's code than I have from any
books!
from Robert Meek dba "Tangentals Design"
e-mail: [EMAIL PROTECTED]
Freelance Windows Programming for XP and Vista
Also proud to be a Moderator of the "Delphi-List" at elists.org
"Reality cannot be explained...only enjoyed or endured as your current
perspective allows!"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Alan Colburn
Sent: Monday, October 01, 2007 6:26 PM
To: Borland's Delphi Discussion List
Subject: Domains, Presentations, and StringGrids
I'm trying to learn good coding practices--keeping my presentation classes
separate from my domain classes. But it's hard sometimes ... the old, newbie
ways just seem easier!
Consider this example: In the UI you've got a StringGrid, which is editable.
Each row in the grid ultimately represents separate objects, and each column
separate attributes or properties. So, what do you do about creating new
objects? In my "old ways" this wasn't an issue--users just type their info
into the grid, and the various operations on the grid are taken care of via
UI form code event handlers ... convoluted, hard to understand, sometimes
difficult to debug--but conceptually simple.
As users, however, we're accustomed to simply typing in a grid a la
spreadsheets. So how is the program set up to recognize when you're changing
attributes of an existing object, and when you want to create a new object?
I know that some people use StringGrids as read only displays and simply
have them display the attributes of each object in a collection anytime
there's a change inside the collection. ... But I'm talking about an
editable grid.
I hope this makes sense! Thanks, as always -- Al
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
