Usage of attribute classes, object groups, and object Libraries

Object groups package all objects and properties in the navigator. Multiple child groups can be created in the object group for classification. When other forms need to use these object classes, they can share the objects by placing the object groups in the object library and saving them as *. olb files. Attribute classes only package attributes. When you share attribute classes in different forms, you must use object groups.

 

Object groups allow you to wrap reusable objects for future replication or subclass division. The object group collects a group of objects in a module under a single title. By copying or dividing subclass of an object group, you can obtain all objects contained in the group. Any object can be combined down to the data block layer, but the project in the block cannot be grouped. The object group must contain the complete data block.

The object library is a module. You can drag an object to the library module to centralize reusable object sets. To reuse the objects in the object library, open the library, drag the objects, and place them in the application.Program. The library can organize objects in one or more tag folders. An object library can contain a single object, such as blocks, windows, alarms, attribute classes, and object groups.

1. As long as the object inherits the object from the object library, and the file name and relative path/absolute path are exactly the same. In fact, all other files are the same. For example, if an application is installed on multiple computers, after modifying a form, copy the modified compiled FMX file to the original file of another computer to overwrite it, MMX files, PLX files, and olb files are the same.
2. Currently, modifications to the object library may only be dragged.
3. Of course, it must be inherited. We recommend that you perform the following checks:
Create a form frm1 that inherits an object in the olb Object Library (such as the background image and canvas background color) and save frm1 as frm2, frm3 ,....
Modify the object attributes in the object library, save them, and observe the changes of each frm.

Tip:
1. check the attributes of the inherited object. If the property name has a red cross sign, the property will not be the corresponding attribute of the inherited Object Library object, even if the property is adjusted to be exactly the same as the property in the object library. To inherit this property, use the red inheritance button above to restore the inheritance relationship.
2. Because the object inherits all attributes completely, it may lead to inheritance of unnecessary attributes. We recommend that you add required attributes to the attribute class and then add the attribute class to the object library.
For example, if the "save" button is used, I want to inherit most of its attributes. Some attributes do not have to be inherited, such as coordinates. The inheritance relationship (Red Cross mark) of these attributes must be damaged first. Otherwise, after modifying the attributes in the object library, the inheritance does not have to inherit new attribute values, which may be a loss, this is easy to ignore. The use of attribute classes can avoid unexpected problems. For example, if a date item is added to an attribute class by alignment of its text, format, width, height, and other attributes, only attributes in this attribute class are inherited. Other attributes are irrelevant, therefore, it is more flexible than directly inheriting objects.

 

It may be the problem that the inherited object is prone to: All attributes are completely inherited. Check the canvas attribute of the button in the object library, such as canvas1, and check whether the canvas exists in your form. For example, canvas12 is used by default when you create a canvas.
Old: To avoid unexpected situations of this class, use attribute class inheritance.
It can be called as long as it is a valid olb file.
Tip: Try not to integrate and inherit from multiple objects. Otherwise, you may encounter problems when deleting the child objects of the inherited objects. For example, create a control block "KZ", including buttons such as "save", "add", "delete", and "exit", and their standard triggers, once the "KZ" object is inherited, all buttons and all their triggers are inherited. You can add other objects in the "KZ" block, you can also modify inherited sub-objects, but you cannot delete any inherited sub-objects. Therefore, to make the inheritance feature more flexible, I suggest the following:
1. Use property class inheritance as much as possible, and use less Object Inheritance.
2. Use single-object inheritance as much as possible, with less frequent multi-layer object embedding.
In addition, I think the additional libraries and object libraries on this forum (attribute classes, object groups ,...) the inheritance usage can meet the needs of application development. You only need to search more and use more practices.

 

 

For example, a trigger can be inherited as an object. An item with a trigger (data item + item trigger ..) it can also be inherited. The trigger that is inherited under this item is a sub-object. The delete operation can only be performed on this item, not the trigger that is inherited under it.
DUI objects that can be embedded with subobjects include data blocks (data blocks + block-level triggers + data items + item triggers...) and canvases (canvas + frame + label + picture ...)
In order to avoid unnecessary trouble during use, we recommend that you use it with caution !!!