Rules 11: Display Component Properties When you need to access other forms, you should not directly access its components. Because this will combine other forms or other classes and user interfaces, and the user interface is often the most prone to change in an application. The best way is to define a form properties for the component properties you need to access. To achieve this, you can implement the set method of the component state and the set method of setting component status. If you need to change the user interface now, replace existing components with another component, then you only need to modify the GET method and SET method related to this component properties, do not have to look up, modify all references to this component. Source code for class. See the code below for details:
private function GetText: String; procedure SetText (const Value: String); public property Text: String; read GetText write SetText; function TformDialog.GetText: String; begin Result: = Edit1.Text; end; procedure TformDialog.SetText (const Value : String); begin edit1.text; = value;
Rule 12: ARRAY Properties If you need to handle a series of variables in the form, you can define an attribute array. If these variables are some information about the form, you can also define them to form an array of properties of the form, so you can use Specialform [3] to access their values directly. The following code shows how to define an item of a ListBox component into a form default attribute array.
type TformDialog = class (TForm) private listItems: TlistBox; function GetItems (Index: Integer): String; procedure SetItems (Index: Integer: const Value: String); public property Items [Index: Integer]: string; end; function TFormDialog .GetItems (Index: Integer): string; begin if Index> = ListItems.Items.Count then raise Exception.Create ( 'TformDialog: Out of Range'); Result: = ListItems.Items [Index]; end; procedure TformDialog. Setitems (index: integer; const alue: string); begin if index> = listitems.items.count the Raise Exception.create ('tformdialog: out of range'); ListItems.Items [index]: = Value;
Rules 13: Use the Additional Side-Effects In Properties to remember: One of the benefits of using properties instead of accessing global variables (see Rule 10, 11, 12) is to set or read the value of the attribute. When you may not intend to gain. For example, you can directly drag the components directly on the form interface, set the value of multiple properties, call special methods, change the state of multiple components, or revoke an event (if needed), etc.. Rule 14: Hide Components I often hear those mad pursuits that are object-oriented to the Delphi form that contains some components declared in the Published part, which is incompatible with the encapsulation principle of object-oriented ideas. They did put forward an important topic, but most people in them did not realize that the solution was actually on their hand, without rewriting the Delphi code, nor will they turn to other languages. The components added to the form can be moved to the Private section such that other forms cannot access them. If you do this, you will need to set some form properties to the component (see Rule 11) and use them to access the status of the component. Delphi puts all of these components in the Published section, because this way can ensure that these domains must be created in the .dfm file. When you change the name of a component, VCL can automatically associate this component object with it in the form. Because Delphi uses the RTTI and TOBJECT methods to implement this function, if you want to use this automatic implementation, you must place the reference to the Published section (this is why Delphi puts all the components in the Published part. ). If you want to know more details, please refer to the following code:
procedure Tcomponent.SetReference (Enable: Boolean); var Field: ^ Tcomponent; begin If Fowner <> nil then begin Field: = Fowner.FieldAddress (Fname); If Field <> nil then Field ^: = Self else Field ^: = NIL; end;
The above code is the SetReference method for the Tcomponent class, which can be called by INSERCOMPONENT, REMOVAMPONENT, and SETNAME. When you understand this, you should not think that if you move the component reference from the Published section to the privated segment, you will lose the automatic accessibility of the VCL. In order to solve this problem, you can add the following code in the form's oncreate event: edit1: = findcomponent ('edit1') as tedit; you should do next is to register these components in the system, when you are After they registered, they can enable RTTI into the compiler and can be used by the system. When you move these types of components to the Private section, you only need to register them once for each component class. Even when registration is not necessarily necessary, you can do this because additional calls for RegisterClasses are beneficial. Usually you should be responsible for generating the initialization section of the form to generate the following code: RegisterClass ([TEDIT]); Rules 15: Object-Oriented Form Wizard (The OOP Form Wizard) for each component of each form Repeating the above two operations are not only very annoying, but also quite wasting time. In order to avoid additional burden, I have written a simple wizard program for this. This program will generate some code that can complete the above two steps, and you need to do it several times to copy and paste it. Unfortunately, this wizard program cannot automatically place the code in a suitable place in the unit. I am currently modifying this wizard, I hope to implement this feature. You can find more complete programs to my website (www.marcocantu.com).