Previous: 9 Toolbars
Next: 11 Tabulated output for screen or printer
In this section:
The mnemonics for the format codes %tb and %ib are derived from respectively toolbar and image bar. The helpfile declares %ib to be a replacement for %tb, but they are quite definitely not, as versions of Windows from 8 onwards have standard toolbar functionality and appearance quite different from that presented by %ib. They are also programmed in rather different ways.
You should not try to duplicate every single menu command on a system of toolbars, but to select the ones most likely to be used and to provide a simple and rapid means of access to those commands. Toolbars and image bars (toolbars generically) can be horizontal or vertical, but they are (in ClearWin) fixed in position at the top or left-hand side of the screen. Where the client area is a graphics drawing surface and has a pivot so it can be resized the upper and left positions keep the toolbars available until the last minute as the master window is shrunk.
The big advantage of the image bar is that it only needs one bitmap for each button whereas the toolbar requires several – the corresponding advantage of the original toolbar is that it looks the way you want it to.
Before you embark on programming toolbars of any sort you should be aware that they are very hard work, generally, because they need icons and those icons must be drawn. It is of course possible to use a toolbar made out of text buttons, but even anything but the simplest toolbar even one largely made out of text buttons can sometimes have associated bitmaps.
As an example, one of my applications has 2 toolbars, with a total of 48 buttons (including the one that is a separator). If you had (for ease of multiplication) 4 icons for each of the four states for %tb buttons, that represents 192 icons to draw, and that is in addition to any other icons used in the program. That particular application of mine has some icons that are always available and never greyed out so they only needed 3 bitmaps to be drawn, but, to make matters worse, the user of that particular program can select between two %tb type toolbars, and three %ib toolbars, amounting to a lot of drawing exercises.
If you in addition multiply the number of icons up by the need to have different sized icons for different screen resolutions, then the number of icons to be drawn becomes a really daunting job, made worse if you really do not have any artistic ability or skill in using a Paint type program. Fortunately, both types of toolbar require .BMP files and not .ICO, so that you can use the MS Windows Paint program.
The sizes that you select for your toolbar icons will depend on a variety of factors including whether or not you intend that your application be usable on a touchscreen.
Taking first the %tb icons, these need to be drawn at about 24x24 or bigger for typical 96 DPI setting screens of small to medium size, but 24 x 24 is far too small to allow an accurate finger selection. If touchscreen access is important then it is possible to consider the use of a rubber tipped stylus as a substitute for a finger press, but if a finger press must be catered for then you need much bigger icon, say 64 x 64. When really big icons are used, they may take over a lot of screen space and there is certainly a limit to how many may be drawn in a vertical toolbar.
With a %tb toolbar, you are responsible for the design as to how a button looks when it is being pressed. For many versions of Windows, the method was to pretend that when the button was being pressed it appeared as though it went downwards. This effect could be achieved with the pixels around the edge of the bitmap. For example, if the top and left edges are drawn with a light colour, and the bottom and righthand edges are drawn with the dark colour, it looks like the button is raised. If the reverse colouring is applied, that is to be darker on the top and lefthand edges and a lighter on the bottom and righthand, it then looks as though the button is depressed. Variations on this very simple technique may be used to signify a button that has been selected. The greyed state button should not then look as though it is selected.
It may be necessary as well to make the image on the icon move down and to the right by one pixel when the button is depressed if that down-up is to be simulated.
Windows 8 and 10 introduced flat buttons, where the visual effects of up-and-down etc. are replaced by colour change.
All button icons do not have images that run right to the edge of the relevant bitmap, and so must fit in a smaller area. For example, in a 16 x 16 bitmap, the graphic itself cannot be bigger than 14 x 14 and may even be several pixels smaller, say 12 x 12 or 10 x 10 when there are 2 or 3 pixels needed for effects on every side. It is very challenging then to draw something that is clear and which also signifies the action that that particular toolbar button represents.
My advice is not to reinvent the wheel, but wherever possible use iconography that has become established through other programs. An example of this is where the File/Save action is represented by an image of a 3.5” floppy disk. Those floppy disks are now almost museum pieces, and the drives are very rarely fitted to desktop or laptop PCs, but the icon is fixed in the minds of users by the fact that it has been used so often. If you look at really old Windows software, you might even find a 5¼” floppy disk represented, but that would be rare because at the time Windows was being introduced the 3½” drive was displacing the larger type of removable media. On such older and obsolete software, you might even find an icon for hard disk but even today the floppy disk icon is taken to mean that as well.
Similarly, the icon for a printer looks like the one in Figure 10.1, and this may be regardless of whether or not the user’s printer actually looks like that! (Note that in the Windows 10 Paint icons, the printer is drawn as a 3D or isometric view. Now that is really challenging!)
Some icons are somewhat ambiguous, because a magnifying glass icon is used for both zooming in and also for searching, the latter being a nod in the direction of the famous Sherlock Holmes who used a magnifying glass to examine clues. Another ambiguous icon is the set of three intermeshed cogwheels that sometimes represent settings but other times are a command button to launch into a protracted analysis. Paint (again) uses a tick to denote settings, whereas it is more usually applied in the sense of confirming a choice in a dialog. Microsoft never conforms to its own recommendations.
I will suppose that you wish to draw the bitmaps with the Windows Paint utility. I will run through the steps to draw a Printer icon, and leave the rest to you.
Open the Paint application and in the File menu select New. Again, in the File menu select Properties and change the size of the icon to 24 x 24 then, zoom in using the slider bar near the lower right corner of the application so that the icon is as big as you can make it. I am going to draw a printer icon and put it on a light background. Choose the colour from the colour picker and make sure that the colour is selected for colour number 1. Using the paint bucket icon in the tool’s toolbar, fill the entire area with that colour. Then select black, choose first the rounded rectangle shape and then the thinnest line. Draw the body of the printer using this shape, and then selecting the true rectangle, draw the paper protruding from the printer.
Then, colour the printer typical office machine cream and the paper white. Add a couple of buttons on the front of the printer with black pixels and then basically you’re done.
If you want a 3D effect, then colour the top row and lefthand row dark and the right-hand row and bottom row of pixels white or at least a lighter colour. If you want to finesse the job, make the next row in from the edges an intermediate colour to the main body of the icon. If you take the icon and copy it, but reverse the colour pattern for the borders, you have generated two of the buttons: one for up and one for down. You can easily produce a selected icon by colouring the background of the icon in a different shade or even putting a red tick mark over the printer somewhere. In that way you can generate your four %tb icons.
Should you decide on a 3D-looking icon, then it is a matter of producing intermediate shades around the black edges of the printer. You might even add little refinements like as well as using black dots of buttons, use a little green light diode that swaps to red in a different icon. If you offset the icon slightly to the left and up you may even be able to produce a drop shadow effect. You might find it desirable to move the icon image down and to the right by one pixel each between the up and down variants. Finally, you might have to produce a greyscale version of the icon for when it is greyed out and that is simply a matter of replacing all the colours in the main icon using shades of grey.
A modern looking variant does not have the 3D effect but instead uses different background colours or other effects.
Here is an example from a working program of mine, linked to a printer icon:
KODE_TOOL(24) = 1 I = WINIO@ ('%^~?tb@&','PRINTER_ON', & 'PRINTER_ON', & 'PRINTER_DOWN', & 'PRINTER_GREY', & KODE_TOOL(24), MGR(8), KB_PRINTER_FN, & ' Summons the printing dialog ')
This particular button has 3 .BMP bitmaps, referenced in the RESOURCES, and named appropriately. The callback function is named KB_PRINTER_FN, and is referenced in an EXTERNAL statement. It just so happens that the Grey code is the 8th element in an array MGR, and the initial setting is given by the value of KODE_TOOL’s 24th array element (the same grey code is used for multiple toolbar buttons, but the status-setting is unique for each one). Only three icons are required because the printer cannot be permanently on, but it does need a greyed-out version because it may not be available when the program starts up or when there is nothing to print.
I found, by trial and error, that the help string looked better starting and finishing with a space character.
I suggest that you will only make progress with toolbars by giving it a try. You could do worse than to take the above example, replacing KODE_TOOL and MGR with single variables and wrap the whole thing in a simple program with a single, do nothing, callback. You will, however, need three bitmaps with a printer icon. Initially, you might draw three icons where the up and down variants are just a different colour, and the grey variant is simply replaced by two-tone grey.
Try your simple program out and see the effect of clicking on the button. The next step is to draw the icons with a 3D effect as shown in figure 10. 2, just to see how the up-down effect works.
Following that, I suggest adding a button to change the grey code and then see what the icon looks like. Decide for yourself whether the greyed-out state looks better with the 3D effect. You might try adding a fourth icon to see how the icon clicks on and off.
As a final experiment, either duplicate the whole button several times to make a toolbar, or draw some more icons so that the toolbar buttons are in a row and are all different. The choice is yours.
After that, what the icons look like and how they function is a matter of your experimentation. Three-dimensional effects are produced by the appropriate shading, with elements looking raised if they are lighter on the top and left and darker on the bottom and right or depressed if the shading is the other way round.
Imagebar buttons come in 3 styles:
The following code snippet illustrates the use of %ib to create a 4-element image bar, with the comparative simplicity of the format relative to %tb with its multiplicity of icons enabling for toolbar buttons to be put in the same WINIO@ function call without it becoming overly complicated, although my advice to limit the amount of data in any such call still applies. The first part of the code examines what version of Windows is running, because the earlier versions do not offer the ms_style of tooltip. The delay is set to 300 milliseconds.
In the second block of code we have the actual toolbar creation, with one of the options for the format code being spliced in with the concatenation operator //, which allows you to select
whichever toolbar style pleases you. Concatenation is also done with the various parts of the format string to enable the use of continuation lines. The string that is inserted (INS) is one of the three options: two apostrophes ‘’ (i.e. nothing), ‘coloured’ or ‘flat’, and the help strings are put in in order within square brackets.
CALL GET_OS_VER@ (ID_Platform, Major, Minor) IF (Major .LE. 5) THEN ! i.e. XP or earlier IA = WINIO@('%th[delay] &', 1, 300) ELSE IA = WINIO@('%th[delay,ms_style] &', 1, 300) ENDIF IA = WINIO@('%?4.1ib[' //INS// ']' // & '[ Zoom in or out ]'// & '[ Screenshot graphics and print ]'// & '[ Print results ]'// & '[ Launch help manual ]&', & 'ZOOM', IMBAR(1), KB_Magnifier_FN, & 'PICTURE', IMBAR(2), KB_Bitmap_FN, & 'PRINTER', IMBAR(3), KB_Printer_FN, & 'HELP', IMBAR(4), KB_Help_FN)
The initial settings of the array variables IMBAR(1) to (4) reflect the status of the toolbar icon. To incorporate this code into a test example, you will also need 4 bitmaps, which I have sketched in a simple form in Figure 10.3 below.
The great advantage of toolbars created using %ib is that you only need one bitmap that ClearWin+ itself transforms into the different states. It is intended by design that these buttons sit on a grey background, typically with the RGB values (192, 192, 192). Using Microsoft Paint therefore, a good practice would be to define a square area (although in principle any rectangle will do) and selecting a custom colour which you define as the grey, fill the whole area. Then on top draw your button icon. You can use whatever colours you like that would show up against the background. I have sketched below four icons that you might draw in the Windows Paint application to try out the code that I have given.
With 4 bitmaps named in your RESOURCES segment, you should be able to program the buttons, and if you have done the imagebar WINIO@ calls 3 times with different INS strings you will see the three styles. As an experiment you should make sure that you examine the greyed-out versions.
One of the fundamental problems is that when ClearWin+ generates a ‘greyed-out’ version of the button because it is inactive, then all that you have drawn will be turned into the same dark grey colour. It probably does not matter if the icon is spindly like the open scissors that typically
signify ‘Cut’, or the Help icon from Figure 10.3, but many of the icons will turn into dark grey blobs, and it is unlikely (highly unlikely in my view) that you will be satisfied by the unrecognisable nature of some of your icons in the greyed-out state.
The solution to this problem is to fill any substantial areas in the icon with a hatched pattern in which your chosen colour and the (192,192,192) background grey pixels alternate. Then, when ClearWin+ generates the greyed-out version of the icon, the hatching still shows. The effect of hatching with the light grey is to make the colours less saturated and more of a pastel nature, but that is unavoidable. The following illustration shows the effect:
The total number of icons that need to be drawn for %ib is so much smaller than for %tb, and this may be a very real incentive to use %ib instead of %tb. At the time of writing, it was possible to add text to %ib buttons, but only underneath and not alongside in line with common contemporary usage. Moreover, the fact that only one bitmap needs to be specified means that it has to be drawn in a particular way in order that the greyed-out state is still recognisable.
Something that is very important is to stick to a particular theme in a given toolbar so that the icons react in a common way.
The next very important issue to answer is what functionality do you really want in a toolbar? Some applications probably only need a toolbar that reflects the contents of the File menu, and then only a subset, as in for example Open, New and Save, with Print actually unconnected with the other icons and featuring to the right of the toolbar near Help icon.
Other applications will need many more icons. Just as in the case of submenu items that are divided by horizontal line separators, toolbar icons also need separators: vertical in the case of horizontal toolbars and vice versa. Unlike in the menu case you will have to draw the separators yourself. I have found that a space character works pretty well with image bar style toolbars, but a drawn separator is required with the %tb format. Rather bizarrely, the separator needs to be permanently selected and therefore not responding if it is clicked on, but also to need a help string that is never invoked!
You might find that parts of some icons are almost reusable, as in for example the sketched icons in Figure 10.5 below.
I have cut-and-pasted three versions of the same toolbar drawn with %ib icons. The bottom version uses %ib[flat], the middle version uses %ib[coloured] and the topmost version uses no qualifier. At program start-up, most of the icons are greyed-out. You can see how the chequerboard effect allows us to see the internal shapes of %ib icons. Running from left to right starts with four icons from the File menu: New, Open, Save and Close, with Save and Close greyed out initially. The rest of the icons relate to the functionality of the program until we come to the last group of four, with the ability to zoom, to take a snapshot of what is on the drawing surface, to launch the print menu or finally the help file.
Once there is a datafile open, the second row of icons in general is selectable, or deselectable. There follows a group of analysis options, followed by another group which can draw, select, label, delete (in this case with an eraser as the icon) or accept. Some more icons follow including a text string that could easily have been put in a status bar that is useful here, and finally a subsidiary icon to rapidly bring up help on what particular mouse clicks can do.
The flat variant makes all the icons look as though they are greyed out, but on mouseover their colours appear.
The following toolbars have been drawn using %tb, reflecting styles very current with Windows XP and Windows 7. These are not options in ClearWin+ but have been obtained by drawing the icons with the 3D bar effect, and at this effect has to be applied when drawing all the icons for the different states of the toolbar buttons. Rather unfortunately, the spacing is erratic with large font settings and this caused gaps to appear in the toolbar. The solution was actually rather simple and that was to draw a bitmap with effectively blank toolbars and put that in the toolbar location at first, before drawing the icons for the toolbar over the top. Then the spacing did not matter but different bitmaps are required for standard and large font settings.
The separator bars are actually drawn as separate icons, where they are not clickable. Separators need to have their own help strings, but they are never used and can be anything you like.
The text string on the second line of the toolbar was originally a typical cartouche, but an upgrade to the %rs output format produced an extra line of white underneath the text string, and until that was fixed by the introduction of the no_extra_space qualification, ruled out the use of the ordinary cartouche and by the time the modification had been made available the underlying bitmap had already been modified, and I actually preferred the result!
Just a quick reminder that of the two methods of defining status bars, the %sb approach (see the online help files) only allows a progress bar as a tool, although it can be added in any panel, whereas status bars defined using %ob[status] … %cb may have all manner of controls, including sliders (such as several MS apps use to control zooming), buttons, icons etc in a multi-line status bar.
Personally, I’ve never needed to put controls into a status bar, nor for that matter, to have any
sort of toolbar anywhere but on the main window of my applications.
While drawing the icons is time consuming and requires those tricks that I described above, there is one nice thing about programming toolbars, and that is that the vast majority, if not all, of the required callback functions will have already been written in connection with the menu bar commands!
I have found from experience that toolbar buttons definitely need help popups, but menu commands and other buttons do not, provided that they operate in standard Windows modes. If you find that you do seem to need pop up (or ‘balloon’) help, it probably means that your action words are not sufficiently descriptive, or that they need to be used in unconventional ways. The solution is in your own hands …
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.