What is an application without buttons? There are two main types of buttons in KOL.

 

Constructors:

NewButton(Parent, s) - creates a regular button that cannot be changed in color (this is how Windows works: someone once decided that all buttons must have a standard mouse color, and since then it has been so, only not all programmers use standard buttons as a result in their applications ).

NewBitBtn(Parent, s, options, layout, bmp, n) - creates a "hand-drawn" button (something like TBitBtn in VCL, but windowed). This type of button has much more options and settings that allow you to set images for it (for several states: the button is not pressed, pressed, inaccessible, the button is by default, or under the mouse cursor), drawing options (flat, without borders, with fixation, with autorepeat, etc.). A significant drawback of such a button is that its appearance is poorly compatible with XP themes.

 

In fact, since Windows XP appeared and became widespread, the use of "self-drawn" buttons is strongly discouraged, as they can seriously spoil the appearance of the application, if not in the standard XP theme, then certainly in some additional. Instead of the BitBtn button, it is quite possible to use a standard button, placing the necessary child controls on it to display the button title, image and any other desired visual elements. This is possible because there is no restriction on how a button window can become parent to other windows. The limitation that is set on the MCK mirror of the TKOLButton can be removed by setting the AcceptChildren property to true. You just need to remember to set these child elements to the transparency of the mouse (MouseTransparent).

 

There are a number of methods and properties specific to buttons:

 

IsButton - returns true for all kinds of buttons (including the radio buttons discussed in the next chapter);

Click - a method that makes the button click and release as if it were clicked with the mouse. In fact, the same is done for any control when calling this method, but it is most used for a button, because it is for a button that such software clicks are visually observed by the user. For all other controls, it is almost always much easier to call the associated OnClick event handler from your code;

LikeSpeedButton - this property was already mentioned as a property that allows you to prevent the control from capturing focus, and for a button it makes it look like a TSpeedButton in VCL;

OnClick - this is the most important thing for a button (it is also present in the general description for all visual objects): because, why do we need a button at all, if we do not handle the events of pressing the button;

 

 

In addition to the general properties of the button, for bitbtn, i.e. for a drawn button, TControl has a whole set of additional properties, methods and events:

 

OnBitBtnDraw - a special drawing event, allows you not only to completely replace the drawing procedure, like OnPaint, but to complete its completion;

BitBtnDrawMnemonic - setting this property to true provides an image of an underline in the text on buttons on a mnemonic symbol that has a prefix '&' (the ampersand '&' itself is not displayed - this is the style that corresponds to the standard behavior of a regular button, with the difference that all drawing bitbtn-buttons are executed by the library code, not the system);

Flat - flat button (borders appear only when the mouse enters the button);

TextShiftX - horizontal displacement of the text on the button when it is pressed;

TextShiftY - vertical displacement of the text when the button is pressed;

BitBtnImgIdx - the index of the image in the image list associated with the button (if only the list of images is used, and not its own bitmap with several reliefs - glyph);

BitBtnImgList - a list of images for the bitbtn button (if used);

OnTestMouseOver - this event is used and generated only for the bitbtn-button (if set), so that the user, with his own code, can set the area in which the mouse is considered to fall on the button. This event allows you to form bitbtn-buttons of a completely arbitrary shape, in which the clicking occurs not on the entire rectangle of the button, but only in the active zone allocated by the user handler;

BitBtnInterval - interval of autorepeat of pressing the button, when the mouse is held down after pressing the button for some time (if 0, i.e. the property has not changed, autorepeat does not work).

 

 

Additional properties of all buttons:

 

DefaultBtn - should be set to true for the button to become the default button. Only one button on a form can be the default button. If there is such a button, pressing the <Enter> key causes this button to be "pressed" when the focus is on the form control (unless this control has the IgnoreDefault property set to true);

 

CancelBtn - cancel button. Similar to the DefaultBtn property, it allows you to define (the only one on a form) button as the "cancel" button that will be triggered when the <Escape> key is pressed on the keyboard when this form is active;

 

For a button, both the DefaultBtn and CancelBtn properties can be set to true at the same time, allowing you to "press" both the <Enter> key and the <Escape> key. But on the form there can be only one button with the DefaultBtn property, and only one button with the CancelBtn property.

 

 

In the case of a "hand-drawn" button (bitbtn), either a single image or an image from an image list (imagelist) can be used. And in any of these cases, up to 5 "glyphs" can be provided - one for each of the states: normal, pressed, disabled, focal, and highlighted. In the case of a single image, the glyphs are arranged horizontally in the drawing, and the number of glyphs provided is based on the size of the drawing (assuming all images are square). In the case of a list of images, the glyphs themselves must be in consecutive index positions in the list, and the number of glyphs provided is specified separately. When directly creating a button with a list of images in Run-time, the number of glyphs is passed in the high word of the GlyphCount parameter (in this case, the low word is used to pass the starting index of the glyph set for the button in the list of images). When configuring such a button in MCK, there is a special design-time pseudo-property for this: glyphCount.

 

Note: Prior to version 2.42, the order of glyphs for states was exactly this: normal, pressed, disabled, focal and highlighted. Since version 2.42, the order has changed slightly, the "button is not available" state now has an index of 1. But this can be reverted to its original state by adding the conditional compilation symbol BITBTN_DISABLEDGLYPH2.

 

It is recommended that BitBtn buttons not be used in new applications, see the alternative method for creating arbitrarily complex buttons at the beginning of the paragraph.

 

In MCK, both buttons have their own mirrors: TKOLButton and TKOLBitBtn. When setting up a mirror for a regular button, you can find in the list of properties, including the image property. Yes, KOL implements the API-supported ability to display some image (icon) instead of text on a button. Although, for me, the text as an image on the button is cheaper in terms of the size of the code.