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
