Common Properties and Methods of Window Objects - TControl

 

Since the TControl object type provides the ability to work with window (sometimes pseudo-window) objects, properties and methods that determine the appearance, shape, size of the window, location (in relation to the parent, or to screen). Also, since windows "enter" into the relationship "parent" - "child window", all visual objects have a number of properties to implement these relationships (i.e., parent objects store a list of child window objects in relation to them, child objects have a link to parent window, and a number of properties for setting the order of work with them in the input focus).

 

All windows in the Windows environment are not just rectangles in which something is drawn, they are also code that works by processing messages sent to windows (from others or from the same application, as well as by the system). It is this code that provides the required functionality. Of course, some of the messages are processed automatically, depending on the type of the created window, and on the various styles and parameters specified during its creation. Moreover, some styles or modes of operation of windows are allowed to be changed in the process of work (and some remain with them while they are alive). That is, event handling is also an important common property of all window objects. And, finally, almost every window can have a number of optional attributes (that is, they can be present for one kind of windows, but for others they are simply ignored).

 

Let's immediately agree on some terms that will be used in describing the properties of window objects. In this context, I call the "parent" of an object not the "ancestor" of the object in the hierarchy of objects, but the "owner" of the object window. Those. the parent of the control object is the visual object in which this "child" object is nested. In Windows, some windows are nested inside others, while the nested windows become children of the parent, which is exactly what is meant when we talk about parent and child windows.

 

Note: in VCL there is a separate concept of "owner" of an object (Owner). The owner is the object that is responsible for destroying the given object when its own lifetime ends. KOL has an automatic destruction mechanism (Add2AutoFree) to provide similar ownership of objects, and when a visual object is first created, its parent window object is automatically owned.

 

Another important term (which I have already introduced above, getting a little ahead of myself) is the Applet. in a sense, it is analogous to the TApplication object in the VCL. The difference from VCL is that in KOL this object is encapsulated in the same TControl object type and is, generally speaking, a window object (representing an application button on the taskbar). There are also a number of differences. Perhaps it is worth noting here that the creation of this object is optional for a simple KOL application consisting of a single form (and in this case, the main, it is also the only, form of the application can successfully play the role of the applet, and then the Applet variable also refers to the main application form). Conversely, you can use additional instances of applets - on your forms, in order to

 

A form is defined in the same way as in the VCL - a top-level window object. These windows are called popups in Windows API terms. Their window parent is the "desktop". This does not in the least prevent us from assuming that the "parent" of a form in KOL is a special Applet object. Those. the coordinates of the borders of the forms are set relative to the entire screen, of course, but the Parent property will show on the Applet - this is done so that using the ChildCount and Children properties of the applet, you can view all the forms of the application.

 

KOL also has the ability to create "graphical" visual objects (and, the choice of such visual elements is much wider than in the VCL). In the following description, I will talk about visual objects, meaning any visual elements on the form, including non-windowed graphic controls. If the combination "window object" is used, then we are talking about the object to which the window is associated, with its own handle of the window registered in the system.