Graphic (Not Windowed) Visual Elements
This chapter will briefly discuss graphical, i.e. windowless counterparts of some window objects that do not have window descriptors. Surprising as it may seem, there is a much wider range of such objects in KOL than in VCL. In addition to the label and drawer, the KOL library provides graphical counterparts for buttons, check boxes and radio boxes, and even for a single-line edit box.
As you know, the main purpose of graphic controls is to reduce the load on the system in the case when the form contains a very large number of visual elements. For example, if you try to implement the game "Miner" for a field of 50x50 cells, depicting cells with ordinary buttons, then you should expect a sharp drop in the performance of even a very powerful computer when you run such an application. (Of course, nobody does that, this example is rather abstract).
Of course, it is always possible in each individual application to independently draw the necessary elements, which do not necessarily repeat the appearance of the simulated visual objects, the same buttons or checkboxes. Sometimes you can go the route of changing the interface to use lists or trees, if this is appropriate for the conditions of the problem being solved. And yet there are still cases when none of these approaches suits, and it is precisely a certain set of analogs of standard visual objects that is required.
This is what graphic visual objects are for. Unlike their windowed prototypes, graphical counterparts do not require a window handle (and do not have their own window at all). They draw themselves, without the participation of the operating system, in the procedure for drawing their window parent, which acts as an underlay.
In particular, this means that graphical visual objects provide a richer set of possibilities for modifying their appearance on the part of the developer than their window counterparts. For example, a regular button in Windows does not allow you to change its color or the font color of its label, and the same applies to checkboxes, which, in fact, are also buttons. [I don't know, honestly, why such a restriction is needed. This leads to the fact that the programmer people, trying to make their interface a little less gray and monotonous, instead of standard buttons start using self-colored buttons, and then it all starts to look worse when XP themes are turned on. In any case, this question should be asked by the developers of the Windows operating system].
For a graphic button, such a restriction on colors is not relevant. In addition, graphics controls in KOL have a number of additional event handlers that allow you to intervene in the drawing process at any stage of the redrawing process in order to provide the desired appearance. Namely, in addition to OnPaint, which allows you to replace the entire main drawing procedure, and OnEraseBkgnd, which replaces the background erasing procedure, there are also OnPrePaint and OnPostPaint. These handlers allow you to fix something before starting the main drawing (for example, change the font style, or draw some parts of the image and exclude them from the drawing area), or fix something (do overdrawing) after the main drawing is done.
When developing graphic visual objects for the KOL library, it is possible to correlate them with XP themes. Moreover, in order for these objects to look "like real", it is enough to include one or two more conditional compilation symbols (depending on how much you agree to increase the size of the application, or keep the size small, at the expense of some of the believability).
In the case of using MCK, in order for the window object to be replaced by a graphical one, it is enough to set the Windowed property to false. In this case, however, you should not forget to add the conditional compilation symbol USE_GRAPHCTLS to the project properties so that all the necessary declarations become available to the compiler (the addition of this symbol itself, even without the actual use of graphic controls, increases the size of the application by a hundred bytes).
For manual programming in KOL, you should create graphical interface elements specifically for this purpose with dedicated design functions. The addition of the USE_GRAPHCTLS symbol is, of course, mandatory in this case too.
