25 Departing from the norm
Previous: 24 The eight elements of ClearWin+
Next: 26 Fools rush in
In this section:
- 25 Departing from the norm
- 25.1 Why?
- 25.2 The graphics
- 25.3 What, no File menu?
- 25.4 Menus
- 25.5 Program organisation
25 Departing from the norm
Early on in the book I produced a sketch of the elements that you often find in a fully configured Windows application. Often, you do not need all of them. When I covered graphics, I made everything scalable so that using a pivot with the graphics area the whole window was resizeable. Sometimes you don’t need a resizeable client area. Then, I suggested that you start your menu bar with a File menu, and again some forms of application do not require you to save your data set or even produce a hard copy of your results. Sometimes, a ‘quick and dirty’ Windows interface is all you need.
25.1 Why?
When I entered academic life it was in an engineering department where students were taught some rudimentary programming using the language Algol, which had a particularly good implementation on the college mainframe (an Elliot/NCR 4120). However, it was obvious that Algol was dying, and so a switch to Fortran was made. Some years later, BASIC became all the rage, and the BBC even produced some educational programs in association with a specific type of computer called the BBC model B. A discussion ensued as to whether or not Fortran should be abandoned in favour of BASIC, with the then Head of Department (who was completely computer illiterate but had other qualities, I suppose) entering the debate with the opinion16 that it wouldn’t be long before all the student entrants would come fully equipped as BASIC programmers and programming in any language wouldn’t even need to be taught! While this debate was raging, I bought my first PC which came with an elementary spreadsheet program called SuperCalc. It was obvious to me that for the simple listing and tabulating programs that most of the programs were all that most of the undergraduate students would ever write, a spreadsheet was all they needed.
In due course, SuperCalc disappeared, and other spreadsheet programs came (and went): Lotus 1-2-3, Quattro (Pro) and eventually Excel dominated. Many things that are far more sophisticated than simply listing and tabulating can be done with these spreadsheet programs, but they do have a steep learning curve to do more, and for me, I find that especially with ClearWin+, I can do many things that I don’t know how to do with Excel17.
What follows is an example. The program exists merely to let me understand and try out the procedures written up, long ago, in a paper in a particular Journal. The framework in which it runs, however, is little different from that which I advocated right from Chapter 1, although slightly simplified. There are 2 simplifications. The first is not to have a scalable window, covered in the following section 26.2. The second departure is to start with initial data specified not via an input file, but in the program itself. The reasons for the second choice are covered in Section 26.3. In this program, that initial data is alterable very easily because there isn’t much of it.
 |
 |
25.2 The graphics
I could not see the point of writing the graphics for this application in a scalable way and so I defined a fixed graphics area of 1250(H) by 600(V). This does not meet Windows standards which suggest that a window should display on a monitor with 800 x 600 resolution, but it is many years since I had a computer with that low resolution and this particular application I wanted to run either on my desktop where one of the monitors has a 1920 x 1080 resolution, or on my much slower lightweight travel laptop that has a resolution of 1366 x 768. The size chosen was a good fit for both.
Indeed, not only was the size highly suitable for the displays on which I intended to use the program but also it could be conveniently divided into two areas each of which was 600 x 600 with a 50 pixel gap between the two. In the end the right hand 600 x 600 pixel area was divided into two vertically and many captions for the axes of the graphs that I drew fitted nicely in the 50 pixel gap.
As it happened, the drawing in the left-hand side of the window was always going to be wider than high and as a result this gave space to write things both above and below the actual drawing. The two graphs on the right-hand side always had the same x axes in every run of the program although not the same as each other), and that simplified drawing them as only the y axes needed to be scaled. I could have used three separate %gr areas, but found it quite convenient to use only one, which meant that I did not need to give any sort of user ID, and the only difficulty if it can be called that was the need for the graphs to be offset by 600 pixels in x, and for one of them to be offset by 300 pixels in y.
Had I wished to fit the whole program onto a laptop with a very limited display capability then it may have been more sensible to have chosen the vertical dimension of the graphics area to be only 500 or 550 pixels, and the width to be say 600, and then to provide a switch via a menu item to go from the display of either the picture or the graphs.
25.3 What, no File menu?
The program runs with a default set of data values the physical meaning of which is drawn on the left-hand side of the pane. This dataset is analysed in two ways resulting in the drawing of the upper and lower graphs on the right-hand side of the window. For my purposes it was good enough to be able to see the results I did not need to print them. The dataset was actually very small and each item in it could be altered independently for which I wrote a set of menu commands and callback functions following which the analysis and drawing would be simply redone using the new dataset.
I did not initially feel the need to put that dataset into a file nor to alter it outside the program but after a while I found it somewhat irksome to always be presented with the same initial analysis. I still did not want to put in the complexity of a complete File menu but I wrote a few lines of code that were necessary to save the last dataset when the program exited and in the same way, when the program was started again it would pick up that last dataset as its starting point. I then discovered of course that if I moved the program to a different machine where there was not a starting dataset then the whole edifice came crashing down so I put in a few more lines so that if the starting dataset could not be found the program would find its own initial values in other words a combination of the two approaches!
I was therefore able to do away with the complete file menu as even File/Exit is somewhat surplus as there is the close box at the top right of the window and if that was not enough, I had added a minimise icon and that allows the system menu to be opened in which there is an additional exit option.
25.4 Menus
There isn’t much point in having a toolbar if the menu items do not have their own drop-down lists of sub-menus, although in the case of this program the Help menu does have two items since it contains not only instructions on the use of the program although those are contained in a single dialog box as the program itself is rather simple, and an About box. Both the instructions and the About box are simply vanity exercises in this case, but both are required if you intend anyone other than yourself to ever use the program.
Similarly, there isn’t much point in having a status bar, and the intended function of the program means that there isn’t any point in making the window scalable.
25.5 Program organisation
The main routine of the program is actually rather short, because after all the COMMON blocks it is simply:
INCLUDE <WINDOWS.INS>
INTEGER, EXTERNAL:: KB_EDIT_GEOM, KB_EDIT_PROPS, KB_EDIT_WATER
INTEGER, EXTERNAL:: KB_RUN, KB_EDIT_CIRCLE, KB_EDIT_RANGE
INTEGER, EXTERNAL:: KB_HELP, KB_ABOUT
CALL STARTUP ! defines initial properties C ... build the Windows framework with ClearWin+
IW = WINIO@('%ca[Spencer method (1967) test]&')
IW = WINIO@('%mi[SPEN]&')
IW = WINIO@('%sc&', KB_RUN)
IW = WINIO@('%mn[Geometry]&', KB_EDIT_GEOM)
IW = WINIO@('%mn[Range]&', KB_EDIT_RANGE)
IW = WINIO@('%mn[Water]&', KB_EDIT_WATER)
IW = WINIO@('%mn[Circle]&', KB_EDIT_CIRCLE)
IW = WINIO@('%mn[Properties]&', KB_EDIT_PROPS)
IW = WINIO@('%mn[Help[Instructions,|,About]]&', KB_HELP,
& KB_ABOUT)
IW = WINIO@('%gr', 1250, 600)
CALL CLOSEDOWN
END
The STARTUP routine reads the previous dataset, written the last time the program ran in subroutine CLOSEDOWN. As mentioned, the minimise icon and the entirety of the Help menu are vanity, and each of the data change callback routines is little more than:
INTEGER FUNCTION KB_GEOM()
C .... Various COMMON blocks went in here
INCLUDE <WINDOWS.INS>
IW = WINIO@ ('%ca[Edit geometry points]&')
IW = WINIO@ ('x1 %rf y1 %rf&', X1, Y1)
IW = WINIO@ ('%nl&')
IW = WINIO@ ('x2 %rf y2 %rf&', X2, Y2)
IW = WINIO@ ('%2nl%rj%8bt[OK]')
CALL CALC_AND_DRAW
KB_EDIT_GEOM = 2
END
There aren’t any checks, and no limits are specified, as it doesn’t really matter if the program crashes!
Subroutine CALC_AND_DRAW is where all the work is done, and most of that is associated with the calculations. All text that is drawn is at fixed coordinates and uses the default font and font size. I found that I wanted a single Greek letter (gamma) and for simplicity, cut a section out of a screen capture and made it into a small bitmap that I pasted in position.
Footnotes:
16. He was wrong, of course. Even the best people are wrong sometimes.
17. And feel disinclined to learn. As an enthusiast for aphorisms, one of my favourites is the one about a general inability to teach an old dog new tricks.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.