A C programmer's Delphi learning notes (2)
Three VCL
"From entry to proficiency", the author's arrangement is really bold. Don't talk about how to put the control on the Form, poured from the VCL. I admire the author's discouragement, straight into the core of the problem, embarrassing the muscles to meat, first place the context to you. You know, this has the risk of losing many readers.
1.TOBJECT, the source of thousands of classes. The RTTI information is placed here, this is the convenience of the single single inheritance.
2. A detail: tbutton.instancesize = 504! It's really wasteful. Algorithm analysis is often used in space for time, which should be used in a spatial replacement.
3. As the subclass of TPERSITENT, Tcomponet has fluidization. IDE uses it to write attributes into the DFM file.
4.TPERSISITENT Entrust TFiler and TStream two auxiliary classes to specifically achieve fluidization. Specific implementations include all owned properties of all ownerships from the RTTI, so that fluidization is transparent to programmers.
5. Non-window control? It is believed to be a compensation for low efficiency.
6.components contains all controls on the form, even if their PARENT is another component container, its Owner is also form.
7.Owner and Parent, two confusing concepts. My understanding: Owner is the holder of the object, and Parent is the prendector of the object.
8. Form elements are not packaged! While the convenience of access, it also leaves a chaotic hidden danger, especially in large engineering.
9. The position of the control position corresponds to the Parent's client area, which enhances my confidence: Parent is the rendering of the object.
10. Frames, strong competitors in the form inheritance. The essence is replaced by polymerization. Yesterday, there was a friend: "I think the polymerization can not replace inheritance." Indeed, polymerization is impossible to replace inheritance, but under the conditions applicable to both, the coupling should be relatively loose, and the package is more completely aggregated. Specific to Frames and form inheritance, I feel Frames when I don't involve polymorphism.
11. Delphi's container class, compared to C STL, from elasticity to efficiency, it is far away, and it is easy to have type security issues. Also, Delphi's RTTI mechanism is strong, it can be slightly difficult. This is a side effect without a template mechanism: the entire generic thinking is not used.
In fact, the authors are very good for beginners: do not deeply depth VCL. Although it is still unpleasant, I should be a prominent.
Four: Standard components are actually a lot of delphi users, they are looking at many VCL components support. Some friends said to me, "In fact, the attributes and incidents are not object-oriented" means that they don't dare to share, I believe he is confused with object-oriented components. In my memory, component is an extension of the object, which is still object-oriented, but has added numerous auxiliary features, including attributes (not C "properties") and events.
1.Form's Components, GroupBox's Controls, Listbox Items, Delphi really likes to use array containers to express organizational structures.
2. There is also a Sleected array, an ITEMENABLED array, oh, the value is also stored by the corresponding item of the Items array.
3.DRAG-DROP. See the title of the book, I don't help but think of IdataObject, Idropsource, IdropTarget several interfaces. In fact, Delphi's drag and drop is much simpler. As far as my understanding, the essence is a DROP notification, unlike COM, packing the data itself. This is why you don't need to support cross-process Drag-Drop. 4. The menu is no longer as a resource, presented to the application programmer, is the Items after the packaged TMENUITEM and organization into nested forms. Two advantages: a) pure one, no longer have a menu resource, the programmer needs to be understood. 2) In the packaging layer, the display menu function is extremely convenient, and the programmer is transparent. To this end, ImageList also packages.
5.Action, which is a two-way event forwarding: each customer control -> action-> onexecute, onupdata-> action attribute change -> Customer controls.
6.OWNER-DRAW, or custom control draws itself? A two difficult choice. From an OO purified perspective, Owner-Draw is really a destruction of the package. Custom controls draw themselves, but they have not worn labor injuries and waste resources.
7.TreeView, tree view. Is XML not good at the expression of the tree? Why don't you give them a combination?
Hey, operability, you can think about it, right? It is hoped that the next few chapters can swindle the beginning of work.
------------------------------------ E-mail: Dream_soft@263.net homepage: www.hisee .NET QQ: 80512698
This article is DREAMER (DREAM_SOFT) original, copyright belongs to DREAMER (Dream_soft), welcome to all situations. Keep the original text and reserve copyright information when reproduced.
