1 First steps
Previous: Contents
Next: 2 Enhancing the File menu and incorporating your existing code
In this section:
- 1 First steps
- 1.1 What happens next
- 1.2 What the statements do – compiler directives and the PROGRAM statement
- 1.3 What the statements do – oddments of FORTRAN
- 1.4 What the statements do – parts of ClearWin+
- 1.5 I did it my way – you do it your way
- 1.6 Discussion of HOMER.FOR
- 1.7 Some homework, or ‘self-managed learning’
- 1.8 Enhancing the Help menu
- 1.9 What’s with the @ symbol?
- 1.10 The parts of a Windows user interface
- 1.11 Do it your way
- 1.12 A note to remember – what are callback functions for?
- Install the FTN95 package, either from a licensed copy or by downloading the Personal Edition from the Silverfrost website
- Run the PLATO integrated development application (IDE)
- In PLATO’s File menu, select New, and from the pop-up dialog, select ‘Fixed format Fortran file’
- Type the following code into the file. PLATO helps by colouring different parts of each statement
1 First steps
The easiest way to get to know ClearWin+ is to give it a try. Start by doing the following:
WINAPP
OPTIONS (INTL, DREAL) ! This can be missed out, but is a habit of mine
PROGRAM HOMER
C --------------------------------
INCLUDE <WINDOWS.INS>
EXTERNAL KB_FILE
EXTERNAL KB_EDIT
EXTERNAL KB_HELP_ABOUT ! KB means KALL BACK to remind me !
IW = WINIO@ ('%ca[Homer]&')
IW = WINIO@ ('%mn[File]&', KB_FILE)
IW = WINIO@ ('%mn[Edit]&', KB_EDIT)
IW = WINIO@ ('%mn[Help[About HOMER ...]]&', KB_HELP_ABOUT)
IW = WINIO@ ('%gr[blue]', 400, 300)
END
INTEGER FUNCTION KB_FILE()
C --------------------------------
KB_FILE = 2
RETURN
END
INTEGER FUNCTION KB_EDIT()
C --------------------------------
KB_EDIT = 2
RETURN
END
INTEGER FUNCTION KB_HELP_ABOUT()
C --------------------------------
INCLUDE <WINDOWS.INS>
IW = WINIO@ ('%ca[About HOMER]&')
IW = WINIO@ ('%si*This is a demonstration Windows program&')
IW = WINIO@ ('%2nl%rj%bt[Dismiss]')
KB_HELP_ABOUT = 2
RETURN
END
Once you have typed everything in, then in PLATO’s Build menu, select ‘Start run’. PLATO will take care of the compilation and linking stages, then execute the code.
1.1 What happens next
What happens next depends on how correctly you typed everything in. If you made syntax errors, then PLATO will tell you what the errors are, and what line number they occurred in. You can count from the beginning, or more helpfully, get PLATO to show you the line numbers. You find the option by:
- Select PLATO’s Tools menu, and select ‘Settings’ (it used to be ‘Options’)
- In the pop up dialog, select the ‘Text editor’ option. The dialog will then change
- Now click on the selection box ‘Show line numbers’
- Close the dialog
It’s always worth having a look at the options, as some of them may suit your style.
If you have corrected any mistakes, then run the ‘Start run’ option again. Repeat until the program works. When it does, you will see an application window like this:
At any point you can save your work by selecting ‘Save As…’ in PLATO’s File menu. I have saved my copy as HOMER.FOR, just to go along with the Greek theme started with PLATO. You can save it under any name you choose.
A point to note is that if you are running things from a Personal Edition installation, you will see the reminder pop up that it is the free version. Apart from this pop up, the facilities are exactly the same as for the licensed edition.
With the very simple code (HOMER.FOR) you have most of the elements of a fully-fledged Windows Application master window – see Figure 1.1. OK, I’ll admit that it doesn’t actually do anything, and it is missing toolbars and a status line – and, although you can drag the window round your screen by grabbing the caption bar, the window isn’t resizeable, but the elements are there. What remains is to learn how the different elements work, and how to program them. I suppose that I’d better explain what the lines of code in HOMER.FOR actually do. The explanation is in the next section.
1.2 What the statements do – compiler directives and the PROGRAM statement
WINAPP : The first two lines are compiler directives. This means that they aren’t Fortran, but tell FTN95 how to go about its business. The first line contains the directive WINAPP. That tells the compiler to compile this as a WINdows APPlication. You don’t have to write a Windows application, and if you’re compiling an old Fortran program then just leave it out. If you put WINAPP into your old Fortran program, then instead of producing its output in a command window or ‘DOS box’, the output will go into a nice Windows text window. If you are going to program a proper Windows application and use ClearWin+, then you need WINAPP, but even so, you will surely want something a lot smarter than simply a program where the output is black on a white background rather than the other way round!
OPTIONS (INTL, DREAL) : the second directive line tells FTN95 to use 4 bytes for INTEGERs and 8 bytes for REALs by default. If you use this directive, then FTN95 stops being standard conforming, because there is no longer a higher level of precision for real variables and a few other things, but it does make programming simpler. Quite a lot of old programs use just the standard integer length and the standard real-variable length, and this just sets them for you in a way that 32-bit Windows 1 demands.
Once again, you don’t necessarily need to use this directive. You can set FTN95 up to treat those lengths as defaults (which is what it does if you install FTN95 with default settings), or you can give them on a command line when invoking the compiler. One of the good things about using these directives is that immediately you try to compile your code with a different compiler it will throw up errors, and that will remind you that once you have sunk a lot of time investment into a ClearWin+ program you are going to be needing to use FTN95. You could also declare the type of every variable and array in your program – you must do it your way. Incidentally, there aren’t any REALs in HOMER.FOR – it’s there for the future!
I have followed the directives with a blank line. I quite like laying out my programs with blank lines, and I do so to space the program into logical groups. There was a time when you weren’t allowed blank lines, and anyway if you were programming on punched cards, blank lines got in the way a bit. A bit? I should say a lot, if you were limited to jobs of 600 cards, including the program and its data, as I once was as a student. I’ve used them all the way through this program demonstration particularly to sub-divide the source code into separate routines’ sections and also into logical blocks.
To save anyone typing in the program, it is downloadable along with the other code fragments in this book. A version in a more modern style of programming called HOMER.F90 is also downloadable, or can be typed from Appendix H.
1.3 What the statements do – oddments of FORTRAN
PROGRAM HOMER : this statement is the header for the main program routine. I have underlined it because that’s another one of my programming habits that I find useful. I also underline all the headers for subroutines and functions. The underlining is done with a comment line starting with the letter C in column position 1. If you like the idea, but don’t like comments beginning in column one, then you can use the exclamation mark symbol (!), and start your comment anywhere on the statement. In fact using an exclamation mark ! means that you can begin a comment anywhere you like in a statement, but then from the symbol ! to the end of the line is all comment. It’s a facility that was introduced with later versions of Fortran and is something that you probably will find very useful if you haven’t come across it before.
INCLUDE <WINDOWS.INS> : The next statement tells the program to look for definitions of various things to do with ClearWin+ in an include file2 called WINDOWS.INS. it is enclosed in diamond brackets to tell FTN95 to look in the standard place for system include files which was set up when you installed the compiler. I’ve followed it again with a blank line.
My standard programming method is to use the IMPLICIT types, which basically means if a variable name begins with any of the letters IJKLMN then the variable is INTEGER, and if it begins with any other letter, then the variable is REAL. I quite like this because it enables me, years or even decades after I program something, to just look at a variable and know what type it is. Many of the current authorities on Fortran programming think that IMPLICIT type is a terrible idea, and that you should use the statement IMPLICIT NONE, and then declare all the variables that you go on to use by their types. There’s nothing to stop you doing that if you want, but I won’t do it, partly because I have both a habit and preference, and partly because it makes all the examples enormously long.
WINDOWS.INS is actually an include file that includes a whole load of code, most of which you don’t need. Eventually, you may want to include only the bits you need, but at first, include the whole lot – it’s easier that way.
1.4 What the statements do – parts of ClearWin+
WINIO@ : a big feature of ClearWin+ is the integer function WINIO@. FTN95 almost always puts the @ symbol at the end of the name of a routine that is provided as part of the package but isn’t part of standard FORTRAN. It’s because @ isn’t part of the FORTRAN character set. In later versions of ClearWin+ you can use $ instead if you wish. The function is declared as INTEGER in WINDOWS.INS.
WINIO@ provides a sort of wrapper with a FORTRAN syntax for many of the functions that are part of Windows. The parameters supplied to WINIO@ are firstly a character string that contains format codes (see below), and then a list of other parameters that may, or may not, include the name of a function (or names of functions) to be executed in response to the user selecting an option. These functions are named ‘callback functions’, and they are always INTEGER.
EXTERNAL : the next three lines in the program declare some function names to be EXTERNAL, which means that they will be passed to subroutines or functions by their names. These functions are used as ‘call back’ functions, in other words, they are what the program has to do if the user makes a command by selecting an option or making the right kind of mouse click. In the demonstration program if you select a menu item, then the function contains the code of what the program does in response. It has to be declared EXTERNAL because the name is going to be given as a subprogram parameter. In ClearWin+, all of the callback functions are INTEGER functions. Another one of my programming habits is to prefix all the callback functions with the letters KB_ which basically reminds me that the name is a callback function name and the K tells me that it’s an integer, although that does mean that I have to spell callback Kall Back!
If you like to declare your type names and you don’t want to use a trick like pre-fixing all these callback function names with an implicitly typed letter, then you can declare all those function names to be integer as well and under the later versions of Fortran you can combine the type definition with the declaration that something is external, for example like:
INTEGER, EXTERNAL :: KB_FILE: the double :: is required if you use one of these combined declarations. I quite like this syntax because it does make the callback routine declaration very obvious. You can actually string the names one after the other separated by commas or use continuation lines, but I have declared them all in separate statements for simplicity and to be rather explicit.
WINIO@ (again): After a yet another blank line, we have an assignment statement with the result of the function WINIO@ going into an integer variable that I have named IW (see the code). WINIO@ is a critical part of ClearWin+. The argument list to this function always begins with a string enclosed in quote marks. Inside that string there are one or more 2-letter mnemonic codes that FTN95 refers to as ‘format codes’. All of the format codes must be prefixed with the percent symbol (%). Some of the format codes are followed by some additional information in square brackets []. Then, there will possibly be more arguments as constants or variables, including a callback function name if appropriate. The format string concludes with an ampersand (&) if the formation of a window is going to continue into the next WINIO@ function call: when a window is to be completed, the final format string should omit the ampersand.
In the first WINIO@ the format code is %ca, which sets up a new window with a caption bar, containing what you have put in the square brackets. The caption bar is there to tell the user what program is being used and is responsive to a click and drag to move the window about on your computer screen.
The next 3 WINIO@ function calls set up three parts to a menu bar, with %mn format codes. The menu titles are given in the square brackets. Just about every Windows program has a File menu, an Edit menu, and a Help menu, plus several more that vary from program to program. Traditionally, the File menu is the leftmost menu item, and the Help menu is the rightmost. I have followed this convention here. When you have developed a full application, you will probably have many more top-level menu items, but these three will suffice for now. I have put each top-level menu item in its own WINIO@ statement because that facilitates slipping some more menu items in later. Hence, taking the menu items one by one, it’s time to examine what they do.
As you know from using Windows, when you click on a menu item, a list of commands drops down. Then, when you click on one of those commands, the program does something. We program that by means of an INTEGER FUNCTION called a callback function. The caption bar does not have a callback function because there is no possible program response other than to move. For the purposes of the demonstration the File menu and Edit menu callback functions basically don’t do anything at all. Therefore, those callback functions have virtually no code except to give a return value to the function. There are three possible return values: 0, 1 and 2. If you give the return value of zero, then when it is received back, it will close the window that invoked it. Giving a return value of 1 or 2 does not close the calling window and although 1 is quite satisfactory, apparently 2 is preferred because it just returns. Using the value 1 makes the calling window refresh itself.
In the third WINIO@ call, there is a fledgling Help menu item. Ordinarily, there would be a comprehensive help file as the first submenu item and the About box comes below a separator. You tell ClearWin+ that you are dealing with a submenu by nesting the square brackets. Once you have done that you do not need a callback for the top-level menu, only for any submenus. The callback routine KB_HELP_ABOUT is the third INTEGER FUNCTION, and it generates its own window or dialog box (sometimes simply called a dialog). There is a bit of a standard about this
particular window where the caption reads ‘About HOMER’. That is followed by first of all a standard icon (with the format code %si). There are several possible standard icons, the asterisk calls up Windows’ ‘information icon’, followed by some plain text. Anything in the format string or a WINIO@ call that is not part of a format code is reproduced verbatim in the window.
Finally, after the text ‘This is ‘ etc., there is a button (%bt) labelled with ‘Dismiss’ that is right justified in the box with %rj, and follows after the text string with two new lines (%2nl). Some of the format codes can have a multiplier like this, although many cannot.
The final WINIO@ call in the main program unit sets up a graphics area (%gr) that is initially coloured blue and which is 400 pixels across and 300 high (it’s a fixed size).
When I said that the application doesn’t do anything, that wasn’t strictly true, because if you selected the About option in the Help menu it pops up a dialog like this one (Figure 1.2):
1.5 I did it my way – you do it your way
I program in capitals, and use fixed format layouts because I’ve always done it that way. You must program things your way. So as an exercise, or series of exercises, you should sort HOMER.FOR out the way you want it. There’s no reason apart from personal preference here, and I don’t seek to impose my preferences on you. Here are some stylistic changes you might wish to make:
- If you like to program in lowercase, then edit HOMER.FOR accordingly
- If you prefer free format, then edit HOMER.FOR and save it with the extension .F or .F90 –don’t forget to let PLATO know that it’s now a free format file
- If you don’t like IMPLICIT typing, then use IMPLICIT NONE and declare the types of all the variables – and delete the OPTIONS directive. You could use KINDs instead of say REAL*8
- If you like to program with MODULEs and USE, then replace the INCLUDE line with USE MSWIN.MOD
On the other hand, you might prefer to enhance HOMER.FOR with your own preferences. Here are some suggestions:
- Make the %gr area bigger
- Change the initial colour of the %gr area – yellow could be a good choice, or red or green
- Add another menu item – say Options in between Edit and Help – don’t forget that it will need another callback function
- Put some more text into the About box, including your name perhaps
- Change HOMER for something that suits you better, but remember to change it everywhere. The PROGRAM name does not have to be the same as the source code file name Another good thing to do at this stage is to look at the Help menu in PLATO. Don’t be daunted, you will get to know it better the more you use it.
1.6 Discussion of HOMER.FOR
So far in that example we have used five separate format codes. ClearWin+ contains many more than that! For example, as well as %rj for right justify, there is also %cn for centre justification. Past versions of Windows have centred buttons, but as I write the convention is to right justify them. The button format code %bt can be given a multiplier, for example, %8bt. Ordinarily without a multiplier, the button is sized to its text label. It may be preferable for you to give multiple buttons all a specific size so that if you have three or four buttons in a row they are all the same width, otherwise ClearWin+ will make them all fit their text and they will be of different widths. Incidentally, there is a habit to put ‘OK’ on a button like this one, but Microsoft recommends that as buttons usually signify some action, they should be labelled with a word that signifies the action that you wish to be associated with clicking on that button. Hence, I have chosen Dismiss rather than OK. A question that you probably have concerns what you get for each of the 8 if you do specify
%8bt. ClearWin+ lays things out on a grid, with the vertical and horizontal spacing given by the current font, which if you haven’t specified anything else is the system font. The system font changes between different versions of Windows, and in Windows 10 is Segoe UI. The height is determined from the font definition in a very simple way, but the width of the grid cells is determined from the average character width, noting that some letters take more space than others. You can show the grid using a %gd format code. I will put one in a revised version of the integer function KB_HELP_ABOUT in a demonstration below, but first I want to discuss something else and that is the ‘new line’ %nl. Essentially, with %nl, the current position in the dialog simply changes downwards by one of the grid lines. If you don’t have %nl, then the next position is to the right of whatever you did previously. Sometimes, you will find that you need to insert lots of %nl new lines, and then you would be better off using ‘form feed’ %ff.
Here is that example with the grid specified:
INTEGER FUNCTION KB_HELP_ABOUT()
C --------------------------------
INCLUDE <WINDOWS.INS>
IW = WINIO@ ('%ca[About HOMER]&')
IW = WINIO@ ('%gd&')
IW = WINIO@ ('%si*This is a demonstration Windows program&') IW = WINIO@ ('%2nl%rj%bt[Dismiss]')
KB_HELP_ABOUT = 2
RETURN
END
I recommend putting as few format codes in any one WINIO@ call as you can, especially something like %gd, because that is really a debugging aid, and you will want to comment it out for production code.
Another question that you are probably asking yourself is “why on earth have we started with the About box (or Help/About – which means the About option in the Help menu) which is surely the most inconsequential part of a Windows program?”
The answer, of course, is that its sheer inconsequentialness is why we start there. The only thing about the About box is that it pops up right in the middle of the computer screen and only goes away when you press the Dismiss button (or click on the close button marked with an X at the top right-hand corner of the window). It does not have a minimise or maximise button and it doesn’t actually do anything. You can also use italics or bold, which you switch on with %it or %bf, and switch off with %`it and %`bf. The ‘off’ switches use a grave accent as a modifier. In a similar way, %ul starts underlining, and %`ulstops it. There is also superscript (%sd%su) that work in the same way, being switched off with a second format code with the grave modifier.
Ordinarily, an About box will contain at least one bitmap image, representing the logo of the application, although including bitmaps is left to later in the book. The About box is a good place to put copyright information for the application, to make a note of programmers’ names, and to credit anyone whose help has been utilised, for example, if they have provided any cursors or icons, or drew any bitmaps for you.
One final thing is that the sub-menu item has the three dots of an ellipsis (...) which means that the menu item launches one or more dialogs. We never use the ellipsis on a top-level menu item, and the drop down menu is one step down from the top level.
My advice is to experiment at this stage with very simple modifications to the About box, simply to get the hang of putting format strings into WINIO@ function calls.
1.7 Some homework, or ‘self-managed learning’
In the Help menu of PLATO, you can select the ClearWin+ option. The first thing that you are shown is an alphabetical list of all possible format codes. Don’t be daunted: there are very many of them, from %ac to %wx. Each one is hyperlinked to a description.
Look at the descriptions for the format codes used so far. What you will probably discover is that each has a number of options that I have not described. The reason for that is because right at the start you don’t need to know everything. Are the descriptions enough, on their own, to let you write your application? Are they a self-instruction manual? The answer to both questions is probably ‘No’, but the deeper you get into the process, the more helpful you will find the sort of information given.
There are several other places where you can find the same Help information. One of those places is the Silverfrost website. Another place is a file named FTN95.CHM which is located in the installation file system for FTN95. On my system, it is at:
C:\Program Files (x86)\Silverfrost\FTN95\FTN95.chm
The way I work is to have a link to that file on my desktop. I often refer to it!
1.8 Enhancing the Help menu
In the example so far, we have had only a single submenu item and that is the submenu to the Help menu. Ordinarily, we would expect the first submenu item to direct us to an online version of the user manual. We can update the WINIO@ line as follows:
IW = WINIO@ ('%mn[Help[User manual ...,About HOMER...]]&'
followed by the two callback function names. The length of the statement would then exceed column 72, and would require a continuation line. If we wanted a separator in between the two sub-menu items we would include it like this:
IW = WINIO@ ('%mn[Help[User manual ...,|,About HOMER ...]]&'
(followed by the callback functions that I have left out).
Personally, I think that having too many menu items in the same WINIO@ call has the potential to cause errors and would therefore suggest that it is better to spread the menu over several statements.
IW = WINIO@ ('%mn[Help[User manual ...,|]]&', KB_HELP_MANUAL) IW = WINIO@ ('%mn[[About HOMER ...]]&', KB_HELP_ABOUT)
Starting the menu command %mn with a double opening square brackets is information that the format code is effectively continued at that particular level, i.e. first level of submenu in this case. Of course, you must not forget to put the new callback function name in an EXTERNAL statement, and also you have to write it. This we could, for the purposes of your experimentation, simply give it the same callback function as the About box but that that would be taking the soft option.
Some versions of Windows ago, Microsoft changed the previous standard help utility which used files of type .HLP to a different utility called compiled hypertext help, which run through the program named HH.EXE and uses a compiled hypertext file of type .CHM. There are no utilities in FTN95 for creating CHM files, and you will need a utility to do so. There are various freeware options on the Internet and several for which a licence fee is payable. I’m going to assume that for the time being you do not actually have a CHM file for your application and so we can make use of one that comes with FTN95. We will use FTN95.CHM. It is easier to specify if you copy it from its default position and deposit it in your working directory, but you can invoke it from anywhere if you know the path. Just to make the Fortran lines shorter I will write the path into a character variable. Then, the callback routine becomes:
INTEGER FUNCTION KB_HELP_MANUAL()
C -------------
INCLUDE <WINDOWS.INS> CHARACTER*(128) FILEPATH
FILEPATH = 'C:\Program Files (x86)\Silverfrost\FTN95\FTN95.chm' CALL START_PROCESS@ ( 'HH.EXE', FILEPATH )
KB_HELP_MANUAL = 2
RETURN
END
What START_PROCESS@ does is to launch the program that is specified in the first argument with the contents of the second argument as the remainder of the command line. To explain this rather better, let me take you back to the early days of time-sharing systems or indeed, to the PC in the days of MS-DOS. You might be able to start the program (imagine it is BOB.EXE) with its own datafile BOBS_TEST.DAT as follows:
C:>BOB BOBS_TEST.DAT (where the program ‘knows’ that the data is in a file)
Or
C:>BOB <BOBS_TEST.DAT (where the program ‘thinks’ that the data will come from the keyboard, but you have it in a file instead)
In effect, START_PROCESS@ tells Windows that you are invoking program HH.EXE with the name of the file that HH.EXE is supposed to open.
There is a related subroutine named START_PPROCESS@ - (note the double P) - the difference being that the first of them launches the program, in this case the hypertext help program HH.EXE and that takes over from your program which will not continue until HH.EXE is closed, whereas the second variant launches HH.EXE as a completely independent process which does not need to be closed before control is returned to your program.
1.9 What’s with the @ symbol?
It’s a shorthand to show that the routine isn’t part of Standard Fortran, but instead is a Silverfrost ‘special’. You can get ClearWin+ to run with other compilers, but they don’t recognise the @ symbol because it isn’t part of the Fortran character set (except in strings) and you have to use $ instead. My advice is to stick with @.
1.10 The parts of a Windows user interface
At some stage, you need to decide what your application will look like, what it does, and how it interacts with the user. Many Windows programs start by putting up a simple graphic in the centre of the screen and on top of all other applications. This at least tells you that something is happening while the program loads – which can be slow depending on the computer it is running on, and whatever else it is doing at the time. When the main window has loaded, this initial graphic can be closed. Some applications, for example CorelDRAW!, allow you to open files from the initial splash graphic. That isn’t very difficult, but it is always best to start with a simple example and get more complicated as you go along. Chapter 17 shows you how to get the splash graphic to show, and then to go away when it is no longer wanted.
However, an initial splash graphic is just window dressing. What you are going to want to do is to prepare an application in a standard Windows form. When this application is invoked, it will look something like Figure 1.4 below.
If you are familiar with the classic Windows application, you will recognise the various features shown in the figure. The whole graphic interface is contained within some sort of a frame which is shown by thick black line. The standard Windows frame varies from version to version of Windows, and in some of them it has rounded corners while in other versions the corners are square. The frame may also vary in thickness and in colour. Everything that you can do in your application is contained within that frame. The application window can be resized with the mouse, as the mouse pointer changes as it moves over the frame. Then, with the left button held down, the frame edge can be dragged to a different size and shape, which it adopts
when the button is released. There are special sensitive zones in the corners of the frame. If you are using a very early Windows version, only the right side and the bottom of the window could be grabbed for resizing. In those older versions there was often an icon in the bottom right corner of the screen on what I have described on the Figure as a status line. This icon is no longer required, and it may in fact confuse the user accustomed only to the more recent versions of Windows.
Along the top of the window is a coloured bar that contains the application name and optionally the name of the current data file in use. In the same way that grabbing the frame allows you to resize a window, and grabbing the caption bar allows you to move the window around the screen. At each end of the caption bar there are some graphic icons that are clickable. The one on the left invokes the system menu, of which more later. The icons on the right of the caption bar include icons that will minimise the screen, maximise it so that it occupies the entire screen, or to close the application altogether. Our caption bar in the example only has the close button, and the caption was fixed at the name of the program only.
Running in a row underneath the caption bar are the top-level menus. The individual items are also clickable, and if clicked will usually drop down a list of further options. The whole set of these menus makes up the menu bar. There is a standard for what the menu items start and finish with. The one on the left is normally File and the one on the extreme right is normally Help.
Continuing under the menu bar you are likely to find a feature called a toolbar. The toolbar contains icons principally, but it may contain some text as well, and these icons are clickable and represent shortcuts to things you can find in the drop-down menus. You might also find that there is a toolbar vertically down the left-hand side of the window, or in exceptional cases down the right-hand side or both.
Some applications also have a reserved area right at the bottom of the screen which we call a status line (or status bar) and in the status line you will find information about the data file you are working on other than its name. So, for example, in Microsoft Word you might find the current page number, the total number of pages, the total number of words and the count of words in any highlighted block of text, the language in use, and some iconic representation of such things as the view you have selected and the zoom factor for viewing the current document. Obviously that selection of information is right for a text document, but other applications might need different things displayed down in the status line.
Finally, the remainder of the window is dedicated to a work area in which you can input data and view results. Such an area is called the client area, and as remarked in the Figure caption above, it may not be graphical at all. Just about all my Windows programs use as big a graphics area or drawing surface as I can manage to provide.
Again, depending on which version of Windows you are using, the application window may reserve space outside the frame for visual effects like drop shadows. Recent Microsoft applications use what they call a ribbon, which is essentially a combination of the menus and toolbars. As I write this document, it is not possible to simply generate ribbons using ClearWin+. There are several modes in which applications may work. What I’ve described above is a very simple, classic, Windows application. There is also something called a multiple document interface (MDI) in which you can work on more than one data file at the same time, switching from one to the other at will. You can program MDI applications if you want in ClearWin+, but this is beyond the simple introduction that I’m giving in this tutorial book. Another approach used quite commonly is to generate multiple copies of the application, each one containing a different data file. I refer to these things as data files, but Microsoft refers to them as documents.
Perhaps I ought to do the same!
Notice how the example program, although short, exhibits many of the features that you might expect in a Windows program.
1.11 Do it your way
It’s always a good idea to try things out for yourself. Part of that learning process is also to discover what doesn’t work. Then again, it’s not my intention to duplicate what appears in the Silverfrost help files. You really do need to gain familiarity with those.
Sometimes you discover that your knowledge of Fortran isn’t that great, either. That’s why you need to have a Fortran reference of some sort to hand.
1.12 A note to remember – what are callback functions for?
Most controls can have an associated callback function – menu items must have a callback, unless selecting them invokes a further submenu. The reason for the menu criterion is that menu selections cause actions to be taken.
In a dialog, the only action buttons are recognisably buttons with clear action labels. Many of them don’t need callback functions, because selecting them simply closes the dialog, and the user can determine which button was pressed and therefore what action to take by inspecting the return code. It is only an action button that may not close the dialog which needs a callback, for example, an action button labelled Clear may require various selections made in the dialog to be changed to default (usually zero or blank) values and the dialog is not closed.
Other controls, such as data input boxes, radio buttons and tick boxes, sliders and so on may have callback functions. However, such callback functions should only be used where one option being selected has an impact on other controls in a dialog, and should not be used as to make those controls into action buttons.
If you don’t understand these suggested restrictions, don’t worry. We haven’t got round to dialog windows yet, and won’t until Chapter 6. When we get to the end of Chapter 6, I will remind you of this section. You should understand it better then, and I will give an example there.
Footnotes:
1. You could use the 64-bit compiler option in FTN95. My advice is not to, especially early in the development process. The memory limitations of 32-bit won’t bother any program from even only a few years ago.
2. You could use a USE statement if that is your preference, e.g. USE MSWIN. FTN95 supports both types.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.