A visual of this type is usually used in an interface where, among the many commands available from the menu, there are a number of the most frequently used operations that can be conveniently performed by clicking on the icon associated with this action. For example, it is very easy for a user to remember that an open folder icon is associated with a file open operation.

 

Sometimes, on the contrary, if the number of commands is too small, the toolbar can completely replace the main menu. Usually, this is exactly the situation with secondary forms, on which their main menu is used extremely rarely (I do not remember a case when I had to use the main menu on additional forms in my projects).

 

A very convenient feature of the toolbar object is that it automatically provides floating text prompts for each button (of course, the application developer determines the text of the prompts). Thus, if not only the name of the action to be performed, but a combination of hot keys by which it can be performed is placed in the text of the hint, then the tool bar also turns into a tool for self-documenting the application, and into a tool for visual training of the user when he is just getting acquainted with the capabilities of the program ...

 

Most often, the toolbars are located at the top of the window, just below the menu. This is the most ergonomic location: if the user, choosing the action to be performed, changed his mind and wanted to execute a command that is in the menu (but which is not among the buttons on the ruler), then he does not need to move the mouse cursor far: the menu is very close.

 

But there is no special need to place the tool ruler on the upper part. Moreover, unlike the main menu, it is possible to place an arbitrary number of tool bars in the window (as long as there is space), arrange them not only horizontally, but also vertically, make them dynamically hidden, etc.

 

In fact, the ruler is a panel with buttons. But one window is responsible for the image and functioning of these buttons. (By the way, I forgot to say: if you need to have a large number of buttons, the ruler also saves window handles, which can be useful for improving the performance of the application and the entire operating environment). The programmer sets only the parameters of the buttons (text, images, features of functioning), and event handlers for mouse clicks on the buttons or on the ruler itself.

 

Object constructor:

 

NewToolbar(Parent, align, options, bitmap, buttons [], imgindexes []) - allows directly in the object constructor to set, in addition to the parent and general options of the ruler, also the list of buttons, i.e. names and / or tooltips for them, and a set of icons in the form of a single bit image. The align property specifies for the toolbar whether it is automatically aligned to the top of the parent window by its own windowing means. This alignment does not cost anything for the size of the program. does not add generic code to the application to align child visuals with parent visuals (as it does when using the Align property of a TControl).

 

There are the following options for a ruler object:

tboTextRight - the text on the buttons is located to the right of the icons, and not below, as by default. Note that this option can affect the appearance of the ruler even if the text in the buttons is not used at all;

tboTextBottom - the text is located under the icons;

tboFlat - flat buttons (the border appears only when you hover over the buttons with the mouse cursor);

tboTransparent - property of "transparency" of the ruler (it is also provided by means of the window itself, and the general transparency is not involved);

tboWrapable - the buttons are automatically transferred to the bottom line when the right edge of the window is reached (should be used only for vertically arranged rulers, since KOL does not provide an automatic change in the height of the ruler window when such a transfer occurs);

tboNoDivider - prohibits drawing along the top edge of the ruler the dividing line, which the ruler window displays by default;

tbo3DBorder - adds a pseudo-three-dimensional border around the ruler (as a result, the ruler is deeply "depressed").

 

The buttons parameter is an array of strings that define for each button its type and its text - in one line. An empty string is used as a sign of the end of the array of buttons, therefore, even if the button does not have a caption, it must be given a text containing at least one space. Note: In order for such buttons to display correctly in Windows 9x, the tboTextRight option must be used. A separator button is specified by the string '-' (ie, the string for such a button contains a single minus sign). To create dockable buttons, the text is specified as usual, but it is preceded by the prefix character '-' or '+' (which one specifies whether the button will initially be depressed or depressed). In order to combine the fixed buttons into groups, after the prefix sign '+' or '-', there is a prefix exclamation mark, for example: '+! x', '-! y'. In a group, only one button can be pressed (this is provided by the window). It is also possible to define a "drop-down" button, which is displayed with an additional "down triangle" sub-button on the right side of the button. The prefix character '^' is used to define the dropdown button.

 

In case the buttons are only for displaying icons, the text in the buttons can still be specified, in which case it can be used to define a set of tooltips. It is also possible to specify the list of tooltips additionally, in which case the tooltips may differ from the text assigned to the buttons themselves.

 

The bitmap parameter can set a bitmap of thumbnails for some buttons. If such an image is specified in the ruler constructor, then the width and height of the icons are taken equal to the height of this image. To use a different width of images, you should initially pass 0, then change the width by assigning a value to the TBBtnImgWidth property, and only then assign the image. In this way, you can also use several images, adding them sequentially (but the width of the icons must be the same).

 

Now is the time to remind about the existence of the LoadMappedBitmap functions and others that allow, when loading an image from resources, to ensure their adaptation to the system colors settings that take place at that moment. These functions can be used to turn a fixed light gray color into the clBtnFace color for displaying button faces, etc. - so that the ruler does not look like a foreign body on the desktop, if the used color scheme differs from the standard one.

 

Thumbnails are considered in the image following from left to right, and are numbered by indices starting from zero. Again, the imgindexes array tells the buttons the thumbnail indices from this bitmap. An important detail: when icons are mapped to buttons in a list of text strings, separator buttons are not counted (they still cannot be pictured).

Moreover, if the array of image indices is less than the number of buttons defined in the buttons array, then other buttons receive indices in ascending order. Ie, for example, it is enough to set an array of a single element [0], which assigns the first button in the array an icon with index 0, so that all other buttons get icons 1, 2, ....

 

When setting a bitmap image for icons, it is allowed to specify special (negative) values ​​in place of its descriptor: as a result, the image for buttons is taken from the system standard set of images for toolbars. The choice of system images is not very rich, but it allows, at least for some of the actions of the standard type, to use standard icons, giving the appearance of the application a certain rigor, and making it easier for the user to remember new icons.

 

It is also possible to use not one bitmap, but a list of images. More precisely, up to three lists. One for the normal enabled state of the buttons, one for the disabled (disabled) state, and the third for the highlighted (hot) state. To do this, initially pass 0 as the bitmap parameter, and then assign the thumbnail lists additionally using the Perform method and passing TB_SETIMAGELIST, TB_SETDISABLEDIMAGELIST, TB_SETHOTIMAGELIST messages. Note: when designing in MCK for the toolbar mirror, there are design-time properties imageListNormal, imageListDisabled, imageListHot, which ensure the generation of the corresponding code.

 

Buttons on a toolbar can be identified by their numeric "identifiers" assigned to them when buttons are added, or by indexes. When programming in MCK, there is (and is enabled by default) the ability to automatically generate symbolic constants that allow you to use identifiers assigned at the development stage to identify buttons. Because the buttons are assigned TB1 names by default. TB2, ..., then when multiple toolbars are used on a form, MCK generates code that specifies the values ​​for such constants more than once. Such code, from the point of view of the compiler, is erroneous and cannot be compiled. To avoid such a situation, you should either rename the buttons (TBOpen, TBSave, ... - and then refer to them in this way),

 

Now I will list the methods, properties and events of the toolbar: