Previous: Appendix G: How and where to look for help documentation
Next: Appendix I: The full code for the Listview example

Appendix H: HOMER.FOR written as HOMER.F90

At Paul Laidler’s suggestion, I modified HOMER.FOR in stages to conform to later Fortran styles: free format, modules (maybe), IMPLICIT NONE and so on. My first try was to compile HOMER.FOR as if it were free format. It failed because of comments starting with C in column 1. It didn’t mind the other initial indents, capitals, implicit type and so on. None of the lines is long enough to merit a Fortran continuation, so that didn’t fox it.

I then removed the OPTIONS line, because it is superfluous, but as FTN95 is configurable, you have to watch that the configuration is still at the original default. You can slip in IMPLICIT NONE, but this is needed in (almost) every routine, as there is no over-arching setting, and even a callback routine needs an INTEGER return code, although usually that is specified as a constant. A nice feature is the multiple declaration of INTEGER and EXTERNAL together. If you forget IMPLICIT NONE, then implicit typing takes over anything not explicitly declared, so is something to watch. DREAL can be omitted from this little program, because there aren’t any REALs anyway, but without it, future developments may cause trouble, particularly with REAL constants even if all the variable names are fully declared.

At that point, I noticed that I was using lower case for ClearWin+ format codes. It’s something that I have adopted because it improves readability. So I tried making everything lower case, and removing the leading blanks. Fortunately, the code is so short that it is still readable, although to my eye somewhat less so than the original. Some capitalisation remains because that is needed for Windows. I decided at the same time to remove all superfluous blank lines and blank characters, just because I could, and some programmers like it that way.

Then I removed the INCLUDE lines. In most places it is only necessary to declare WINIO@ to be INTEGER, and the rest of the included information is redundant. However, doing that means that you have to keep remembering what to declare every time you use another ClearWin+ option. Using a MODULE via the USE MSWIN.MOD statement is effectively the same as the INCLUDE line.

I didn’t go so far as to put multiple statements on one line, but I did remove the continuations of WINIO@, just to show firstly that it could be done, and secondly what it might imply. For the line in the main program routine, it still works, but imagine what it would be like with say 10 main menu commands and an average of 6 submenu items in each, That’s 60 callback functions. If say half of those are potentially greyed out, then the 30 grey code settings would be interleaved with the callback functions. Now perhaps add bubble help, icons and the statement would simply become difficult to edit. Hence my recommendation to keep as few items in a WINIO@ call as possible, both to ensure readability and also to facilitate adding or removing items during program development and updating.

There was no reason to keep the KB_ prefix to the callback function names as they are all defined as INTEGER. So here is the end result:

winapp
program homer_free
implicit none
integer w,winio@
integer,external::file,edit,help_about 
w=winio@('%ca[Homer]%mn[File,Edit,Help[About Homer ...]]%gr[blue]',file,edit,help_about,400,300)
end
integer function file()
file=2
end
integer function edit()
edit=2
end
integer function help_about()
implicit none
integer w,winio@
w=winio@('%ca[About Homer]%si*This is a demonstration Windows program%2nl%rj%bt[Dismiss]')
help_about=2
END

So what did I learn? The first thing is just how important to my style of programming the blanks and blank lines are (thanks Kreitzberg and Schneiderman). With this demo, the loss of the leading 6 blanks is no great deal, because there aren’t any statement numbers, but if there are, the initial indent is useful in highlighting those numbers so that they can be found more easily. Statement numbers are fine if they have a regular ‘stride’, are used sparingly, and even with the odd GO TO, they don’t do much harm. If you prefer the forms that avoid numbered CONTINUEs, you really do need to use indentation, and probably blank lines too.

Following that, it confirmed in my mind that the advice to keep the WINIO@ call contents short is good, both for readability and for development. Then, I learnt that wasteful though INCLUDE <WINDOWS.INS> or even USE MSWIN might be, either of them is handy during development as all the definitions are always available.

As an aside or two, for me, the loss of capitalisation does seriously affect readability, but it may not for some people, for example the letters of New York authoress Helene Hanff in her book “84 Charing Cross Road”. (The book was once serialised and dramatized on BBC TV, and subsequently made into a film in 1987). I’d feel the same about the loss of punctuation in my writing. Yes, I know that many people regard all capitals as equivalent to shouting, but the mix of cases is useful. It wasn’t always thus, indeed, the noted geotechnical celebrity Karl Terzaghi in 1939 had his consulting report typed in 2 sizes of capitals, the larger ones taking the place of real capitalisation, while still being monospaced. I didn’t find the presentation nearly so annoying in his 1939 report on a visit to the Folkestone Warren landslide as his apparent lack of technical understanding notwithstanding his celebrity! (It’s a big landslide complex, not Chalk dissolution, Karl, and the sea removed the ‘missing’ material).

The point is that style is a matter of personal preference; readability and the potential to modify are more important than style, and correctness beats the other things hands down.