I have always stayed away from using Delphi's DBGrid because it gave me the feeling of being in the cockpit of an airplane without a clue, as to what all the controls are, or even where to look first. I've decided to roll up my sleeves and get over my fear and anxiety of Delphi's DBGrid.
I'm currently using XE4 and I've been struggling with data validation within a DBGrid as you can see from a recent SO post How to get the value that caused the TDBGridInplaceEdit error?
After reading the answer I got from @bummi, I started googling related topics. Then I remembered I have a copy of Borland's Delphi 7 Developer's Guide.
I quickly turned to Chapter 25 and found all the information I need to know, written in a friendly and very informative way. It's perfect. Each topic builds upon the previous topic giving a full treatment of the subject matter. Here is the table of contents for Chapter 25 of Borland's Delphi 7 Developer Guide:
Chapter 25 | Page |
Working with field components | 25-1 |
Dynamic field components | 25-2 |
Persistent field components | 25-3 |
Creating persistent fields | 25-4 |
Arranging persistent fields | 25-5 |
Defining new persistent fields | 25-5 |
Defining a data field | 25-6 |
Defining a calculated field | 25-7 |
Programming a calculated field | 25-8 |
Defining a lookup field | 25-9 |
Defining an aggregate field | 25-10 |
Deleting persistent field components | 25-11 |
Setting persistent field properties and events | 25-11 |
Setting display and edit properties at design time | 25-11 |
Setting field component properties at runtime | 25-13 |
Creating attribute sets for field components | 25-13 |
Associating attribute sets with field components | 25-14 |
Removing attribute associations | 25-14 |
Controlling and masking user input | 25-15 |
Using default formatting for numeric, date, and time fields | 25-15 |
Handling events | 25-16 |
Working with field component methods at runtime | 25-17 |
Displaying, converting, and accessing field values | 25-18 |
Displaying field component values in standard controls | 25-18 |
Converting field values | 25-19 |
Accessing field values with the default dataset property | 25-20 |
Accessing field values with a dataset’s Fields property | 25-21 |
Accessing field values with a dataset’s FieldByName method | 25-21 |
Setting a default value for a field | 25-22 |
Working with constraints | 25-22 |
Creating a custom constraint | 25-22 |
Using server constraints | 25-23 |
Using object fields | 25-23 |
Displaying ADT and array fields | 25-24 |
Working with ADT fields | 25-25 |
Using persistent field components | 25-25 |
Using the dataset’s FieldByName method | 25-25 |
Using the dateset’s FieldValues property | 25-25 |
Using the ADT field’s FieldValues property | 25-26 |
Using the ADT field’s Fields property | 25-26 |
Working with array fields | 25-26 |
Using persistent fields | 25-26 |
Using the array field’s FieldValues property | 25-27 |
Using the array field’s Fields property | 25-27 |
Working with dataset fields | 25-27 |
Displaying dataset fields | 25-27 |
Accessing data in a nested dataset | 25-28 |
Working with reference fields | 25-28 |
Displaying reference fields | 25-28 |
Accessing data in a reference field | 25-29 |
I've already printed out Chapter 25 and plan to study it this weekend. The manual is 1,106 pages long. I plan on printing the chapters I need as I go. And yes I did buy paper that's already punched with 3-holes.
I don't care what version of Delphi you are using this manual is relevant and will make your life easier. Download your copy of Borland's Delphi 7 Developer Guide now!
If we could only get EMBT to create an updated version of this Delphi classic!
Semper Fi,
Gunny Mike
end.
You know what's sad? I remember developers bemoaning the sad state of the Delphi 7 help compared to the "good old days" of the Delphi 2 help.
ReplyDeleteI'm with Anthony. The D1 and D2 docs were the last time Borland/CodeGear/Embarcadero really cared about decent documents.
ReplyDeleteAfter that, it went downhill FAST - First with the quality dropping so far even the quickstarts were filled with errors so bad you couldn't actually do what they said (no one sat down and tried to follow the instructions before the major print I guess) to erata in the chapters was even worse.
And books dropped off the radar as the price skyrocketed until eventually there were no books, useless helpfiles and the Delphi team acting like we were ungrateful bastards if we voiced complaints about it.
The so called wiki website that is the current effort is, at best, almost adequate if you don't want much out of it - but still a shadow of the quality found in the D1 and D2 help files.
The trend has spread even to the MSDN reference materials. I don't even bother installing the help files any more, and since MS switched MSDN over to use BING, I would rather hit myself in the head with a hammer than search it for anything - I stand a better chance of evoking a meaningful memory than finding anything in their "help system".
Frankly, I could do with a bit of Win95's index every word feature back in play.
I agree. These documents were so well written that I would settle down in a chair all afternoon reading chapter after chapter. We need something like this for XE4/5. From A to Z of the product. I know there are the wikis, but having a book still rocks! Let's have Wiki's, PDFs, and Printed physical books.
ReplyDeleteI remember reading the Developer guide cover to cover - may have been the Delphi 6 version. But yes, they were pretty good.
ReplyDeleteThe old docs were excellent. I have been saying for years that when a document goes non-linear, the content goes to hell. Checking coverage is an issue, and little to no attention seems to be paid to the actual value of the content. I am guessing that they have a tool which checks for topics which have text, but no real vetting of the text is done. So they believe they have coverage, even when what it says it "Embarcadero Technologies has no more information on this topic."
ReplyDeleteAnd who on earth would have approved of THAT message, in the first place?
When you write books, then proofreading is a simple affair, albeit something which takes time to do well, as does coherent writing. Back in the day, the Borland books set a high standard. I cling to the ones I still have, and regret ever having given any of them up.
William, the first version of my software was a DOS based version. I created a 9" x 6", 96 page, perfect bound manual to go with it. I could place the 5.25" floppy or 3.5" disk in the middle and ship it in a catalog envelope.
DeleteSome of us really miss having a well written, printed manual from EMBT. Does that mean our customers also miss having a manual? Should we go back to old school methods of printing manuals for our software?
Gunny, there is another that we all should have:
ReplyDeletehttp://www.amazon.com/Delphi-Component-Design-Danny-Thorpe/dp/0201461366/ref=sr_1_2?ie=UTF8&qid=1377539722&sr=8-2&keywords=danny+thorpe
Mine is secure. ;)
Mine is secure as well. ;-)
DeleteI miss the days when you pressed F1 and got a help topic that was not only correct, but also contained a nice and short code example. I learned Delphi that way!
ReplyDeleteI am a devoted paper manual printer too. :-) If you are printing your own manuals, I recommend using a comb-binder. It puts a heavy plastic spine with fingers that fit into rectangular holes in the pages and covers. You can either buy one ($$$) or have your manual comb-bound or spiral-bound at most office supply stores. I use a duplexer on my laser printer and comb bind my own double-side printed manuals. They lay flat on the table when open and the pages don't fall out as easily as 3-ring bound pages.
ReplyDelete