I think Chris had a really good idea there. I also use flags, but
in the case of databases I tend toward using non-data-aware controls so that
I don't experience a lot of the problems like he mentioned. When I DO use
data-aware controls, I never allow their datasource components to have their
auto-edit properties set to true. This also gives me more control, and
allows me to use my own encryption methods on data being input.
But back to your use of a stringgrid...no matter how you approach it
you must make use of an event somewhere to update the object with the data
entered. And whether you use an event of the Grid, like it's OnEnter, or
onChange, or you provide a button click that updates your object with the
new data entered, or employing dB-like methods such as one event to add a
new record, another to edit, and so on, you should still have these events
only pass information over to the object code and initiate it's own methods
to handle all the work. Even if re-use isn't a concern, this helps keep
your code easier to manage and read later on.
The few times I've had to use a stringgrid for both entry and
display, I've always done what Chris suggested. I use separate,
database-like events from a set of controls below the grid to add, edit,
delete, update, and move from row to row, making sure only the currently
selected or row being added allows input.
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: Tuesday, October 02, 2007 8:06 PM
To: Borland's Delphi Discussion List
Subject: Re: Domains, Presentations, and StringGrids
Hey Robert --
Thanks for getting back to me. Good to hear I'm not alone in my struggles
:-) I'm not struggling with creating objects, collection class objects, etc.
(Perhaps I've received enough answers to questions on this list over the
months that I'm OK with these things now.) Also, I'm not having
difficulties now--I'm just looking ahead to the next thing I plan to do.
I can see, for example, how I could have edit boxes in which to enter
values, and use a button click event to add a new object (with attributes
from the edit boxes) to a collection. The last line in the Add method would
call code that repainted the grid with info from all the collection objects.
However, in most applications the same grid is used for displaying info and
also inputting new info. I was just curious about the "normal" ways of doing
this. If you were going to initially show your grid with 100 rows, I suppose
you could initially also make 100 objects for the collection, each with
blank attributes. As text was entered into grid cells, object attributes
would be changed. Somehow this seems inefficient ... I figured there are
better ways.
Thanks again -- Al
----- Original Message -----
From: "Robert Meek" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Tuesday, October 02, 2007 2:11 PM
Subject: RE: Domains, Presentations, and StringGrids
| 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
|
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
