Previous: 18 Some more about graphics
Next: 20 Beat the clock
In this section:
Some of the format codes are used so infrequently that when writing a second application it is quite possible to forget that they even exist or to forget how to use them. It is a good idea to look at your previous codes and refresh your memory from the online help file.
One example of something I only use once per application is to change text on the caption bar of my master window. I never do it with dialog boxes. My use is to add the datafile name to the program name. You create a dynamic caption by putting the symbol ‘@’ in the %ca format code and give the text as a variable in the parameter list of the WINIO@ function call. So, for example when setting up the master window, we might have:
CAPTION_TEXT = 'Play Beethoven'
IW = WINIO@ ('%ca[@]&', CAPTION_TEXT)
Then, somewhere else in the program, after a file named (say) ‘MoonlightSonata.MUS’ we might wish the caption bar to read:
Play Beethoven + Moonlight Sonata
In this case, the datafile name would need to be trimmed of its extension, a space inserted to open up the camel case, and the resulting filename concatenated with the original program name, before assigning the resulting string to CAPTION_TEXT, which would, of course, need to be in scope. I always find that COMMON is my friend with things like keeping a variable in scope, but if you do prefer to work in terms of modules, then that is perfectly satisfactory too. The only limitation is that the character variable CAPTION_TEXT needs to be long enough to contain whatever you want to put into it, and when joining a file name to a program name it might be necessary to strip out most of the path information.
There is a school of thought that on entry to a new datafile that its filename should be set to something like ‘Untitled.dat’ so that File/Save does not need to bring up the standard Windows file opening dialog, and why not, as Save As is available if you want to change the name. That’s not my preference, but it could easily be yours, in which case it might be useful to put the filename into the caption right from the start.
I write this as a reminder not to forget to put in an %ew format code so that the data file contents are not lost when Windows is shut down. You will need it as well as %cc.
All of my applications tend to have a master window that is rather unique and all the dialogs have a common set of appearances. A number of the format codes are all about the appearance of a particular window or dialog. Two very important format codes are %ww and %sy, the former applicable to any dialog, but the latter only to the master window. I find that with the client area
filled by toolbars and a drawing surface, a border simply takes up valuable space and therefore I tend to use %sy[no_border]. However, when the drawing surface extends down to the window frame, the whole window appears somewhat unbalanced because of the caption, the menu bar and any toolbars on top of the window. Normally, therefore, I add a status bar to balance things up.
When using %sy[no_border], the background colour for the window is rather redundant, but when setting a background colour, I find that the use of a colour that is one of the normal Microsoft Windows settings makes more sense than using a custom colour because it fits in and does not look so garish, for example, %bg[btnface].
For dialogs I also have some useful rules of thumb, including the default font to use and its size. If the screen is more than 1000 pixels high, then the default size tends to be okay, but smaller than that and it is useful to reduce its size to about 0.9 of the standard size - if the application has to run on anything before Windows Vista, the default font may be MS Sans Serif, which would need to be reduced by a factor of 0.8. Later versions of Windows used the font Tahoma, and then Segoe UI.
A routine called WINSTYLE@ was added in order to provide a default style for all subsequent
WINIO@ windows.
SUBROUTINE winstyle@(FORMAT)
CHARACTER*(*) FORMAT
FORMAT is the same as the first argument of WINIO@ but has no other arguments. Its use is restricted to the following format codes:
| %fn Font name |
| %bf Bold font |
| %it Italic font |
| %ul Underlined font |
| %ts Text size (in the new form %ts[value] where value is a floating point number) |
| %tc Text colour |
| %fb Button font |
| %ww Window style |
| %sy Dialog style |
| %es Escape key closes the window |
A terminating ampersand (&) for continuation may be used but is not required. The WINSTYLE styles then apply to all subsequent windows. Example code is given in the enhancements file under item 385.
Another thing that you quite possibly only need to do once per application is to add a ‘minimise icon’ to your master program window. The format code for this is %mi, and the icon needs to be 16x16. Adding a minimise icon to a window allows it to show in the taskbar when the window is completely minimised, which is a good thing, but it opens up access to an old feature called the system menu that allows a window to be maximised. For a dialog box that should be fixed in size, the system menu is a disaster, and as a result, dialogs should not get a minimise icon.
Quite a number of ClearWin+ controls can accept a pivot which means that they will resize if the window containing them is resized. Certainly, you will probably want your main program window to be resizeable, and if you follow my route which is to have the entire client area occupied by a %gr drawing surface, then that might be the only pivot that you have in your whole program. Users do not normally expect most dialogs to be resizeable, but rather they expect them to be fixed size and therefore that the various controls are laid out in a familiar fashion. The only exception is when the program is displaying something that could, if necessary, be tucked out of the way, such as a dialog in which there was a graph. As well as tucking it away, it might be useful to have the graph expanded to occupy the whole screen so that its detail could be inspected. I think of these types of dialogs as ‘High Status’. They do benefit from using a pivot.
Just a reminder: the %pv goes before the format code for the resizable control, and despite my suggestion that you keep as few format codes as possible in any WINIO@ call, it is probably a good idea to keep the %pv in the same call as the resizeable control, as that makes it ‘connect’ when you read the source code.
Footnotes:
14. A catchphrase from the BBC TV sitcom series `Allo ‘Allo
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.