At this, perhaps, it is worth pause and stop for a while the story about all sorts of "simple" objects produced from TObj. The fact is that very many of them, in the future, either interact with visual objects, or are useful only in the presence of visual objects. For example, dialogs, menus, even timers - they already need window objects to function properly. So now is the time to start describing the most important part of KOL - the TControl object type.
The xHelpGen utility for KOL provides a lot about KOL (and you can learn more by looking at the source code). But, unfortunately, much less information is available about MCK mirrors and about visual programming of MCK projects, so I will dwell on this point in more detail in the next article. The previous objects are objects of a significantly more temporary nature than what it would make sense to call "components" and customize at the time of form design. Therefore, they do not have MCK mirrors, except for graphical tools, the properties of which can be adjusted together with the properties of the visual objects that own them. The exception is TImageList, for which there is a mirrored TKOLImageList component.
As I mentioned at the beginning, the TControl object in KOL is not some basic type from which all visual objects corresponding to different types of windows would inherit. In the KOL library, all the main visual objects are encapsulated directly in TControl, similar to how it is implemented for data streams (TStream) or for graphic canvas tools (TGraphicTool). Visual window objects are created by various constructors, which all return a result of the PControl type, but the appearance and behavior of the resulting objects differs (it is in the constructor that it is determined what kind of functionality the created control element, or "control", performs - I will call them that and sometimes hereinafter , to be short).
When designing the TControl type in this way, I had to resort to some tricks. Not only function pointers are used, but also tables for handling the most common messages, and dynamic event handlers, and all kinds of flags. All this in order to save the size of the involved code, and for different "controls" to perform different required actions, if possible, with the same code.
In many cases it was possible to achieve "functional polymorphism", when the same method or property, without changing the name, performs different (but similar in meaning) work for different types of "controls". But sometimes it was not possible to do this, and for all such methods and properties that do not apply to all types of "controls" at once, the source code contains clarifications for which cases they can be applied. For some visual elements that have a large set of additional properties and methods, the names of these properties and methods contain a two-letter prefix that identifies the type of element to which they only refer (LV - list view, TB - tool bar, TC - tab control, TV - tree view, RE - rich edit, etc.).
