Shell App
Volume Number: 1
Issue Number: 12
Column Tag: Fortran's World
A Shell Application
By Mark E. McBride, Miami University, Oxford, Ohio
This month's column deals with designing an application shell to be used with
ported Fortran programs. While the basics of an application shell have been
documented in other MacTutor articles, I felt a shell in Fortran would give users a good
starting point for integrating their ported programs.
Porting to a Shell
Most mainframe Fortran programs can be viewed (at least for our purposes) as a
straightline or sequential process. The user starts the program, it executes (probably
not in a pure straightline fashion), and it stops at one or more predefined points in the
code. Rewritng this straightline code into a Mac user interface will probably
(always?) involve massive restructuring of the code. Given that the third of the stated
goals in the previous month's column was minimizing conversion effort, complete
restructuring is likely to be undesirable in a large number of situations. This
presents the basic dilemma: the user wants to port Fortran programs from the
mainframes with a minimal amount of conversion effort, but the user does want to
include a Mac user interface.
One solution to this dilemma is to treat the ported program as a subroutine, to be
executed upon request from a menu choice. This let's the user have a covering
application shell which has the standard Mac features available until execution of the
ported program begins. Just before starting execution of the ported program, the Mac
features can be completely or selectively disabled. Upon completion of the ported
program, the user is returned to the application shell. This design gives the user the
ability to rerun the ported program several times without exiting to the desktop.
Of possibly greater benefit to the user from this design is that it provides a
starting point for integrating the ported Fortran program. If no further integration is
desired, none needs to be done. However, in the application shell the user has the basic
structure in place for integrating those Mac features desired to the ported program.
This could even include importing information via desk accessories and/or cut, copy,
and paste. Users have the freedom to integrate as much or as little as they like.
The Shell Program
The application shell given in Listing 1 has parentage from several other
programs. The initial basic design came from the Demo.for program included with
MacFortran. However, the program goes well beyond that demo. Design ideas also
came both from a translation to Fortran of the sample edit program on the developers
disks (graciously provided by Absoft) and from previous MacTutor articles. I find that
the assembly shell by Dave Smith (Vol 1 #'s 3 and 4) and that the C Workshop series
by Bob Denny (Vol 1, #'s 2 thru 7) very useful for design assistance. Reviewing
these articles yields many insights into the program design. In fact, I wrote the shell
mostly from review of the aforementioned articles and program listings, with very
little direct reference to Inside Macintosh. The program is written using MacFortran
version 2.1, now being distributed by Microsoft, and in particular, uses the include
files from the 2.1 version.
Fig. 1 Fortran Compilation
The shell program makes heavy use of the toolbox using the toolbx.sub subroutine
calls. Toolbox procedures that return a value are accessed by the toolbx function call.
For example: mywindow = toolbx (FRONTWINDOW) would return a pointer
(integer*4) to the front window on the screen to the variable my window. Toolbox
procedures that do not return variables are accessed as a toolbx subroutine call. For
example: call toolbx (DRAWMENUBAR) executes the toolbox routine that draws the
menu bar given the current menu list.
Given that MacFortran does not type or range check values passed to the toolbx
routine, it is a good idea to compile your programs using an implicit none statement in
the main and all subprograms. This forces the compiler to report any undeclared
names. This is particularly important for the names for the toolbx calls.
[Access to information contained in toolbox parameters is done by defining
appropriate length data constructs, then using equivalence statements to access those
elements needed. In converting this program from 2.0 to the Microsoft version 2.1, a
problem arose regarding the use of the include files. The include file for the Event
manager contains the definitions to translate the Pascal type event record structure
into a fortran array. Equivalence statements then equate labels such as what, where or
modify to the appropriate array item. In most of the include files, only the dimension
statements are given; the equivalence statements should be in your main program.
However, in the Event include file, equivalence statements are given for the event
record array to the typical MDS field names mentioned above. Since this include file
must be present in all your subroutines, a subtle error can occour where an
equivalenced variable (from the Event include file) is also referenced as the dummy
arguement in a subroutine parameter list. In the program listing in figure 1, I had
this problem. Rather than change the include file, I used another dummy variable,
mouse, to replace the where(1) field in the parameter list for the Menu subroutine,
thus eliminating the conflit with the fact that the where(1) variable was equivalenced
to Event record(6) in the Event include file. A cleaner way to solve this problem, and
what you should do is to remove all the equivalence statements from the Event include
file and any other include files, leaving those files only for variable definitions.
Instead place the equivalence statements in your main program and that way, they
won't conflict with dummy variables in external subroutine calls. -Ed.]
Examination of Listing 1 reveals that the program consists of three main parts.
First, the main program initializes the menu bar and window using resources created
by the Rmaker utility. Listing 2 gives the input file for Rmaker to create these
resources. Rmaker is extremely picky about syntax. For example, a blank line means
a blank line; there can be no characters other than a carriage return in that line. Use
the show invisibles option of the editor to locate any extraneous characters. The
resources are retrieved using toolbox calls (e.g. GETMENU).
During the initialization of Mac features, the default I/O window provided by the
MacFortran run time library is removed by getting a handle to it using window =
toolbx (FRONTWINDOW). The window is then closed by call toolbx (CLOSEWINDOW,
window). This is all well and fine, except when you try to run the debugger on a
program that removes the default window in this manner. When you are using the
debugger, the call to FRONTWINDOW will return a handle to the statement list window
since it is the active front window on the screen, rather than the defualt I/O window. I
typically do not close the default I/O window until the program is fully debugged
A further note about the debugger is in order. Given the resource file shown in
Listing 2, the debugger will not work, because the file type and creator have been
changed to allow a custom icon. The strategy for debugging that I follow is to have two
resource files: the full file that includes icon resource information and bundling
information, and another shorter resource file, that is compatible with the debugger
(ie does not have icon, bundle or fref resources). This second resource file adds
resources to an existing file by using
!Shell apl
at the start of the file to identify the existing unlinked compiled code file. The
only resource types added are the menu, window, and dialog definitions. This allows a
fairly smooth process for debugging. The source is edited, then compiled with the
symbol table option for debugging on. From the compiler transfer menu, I use the
select application option to transfer to Rmaker to add the resources. Then I can run the
interactive debugger on the compiled code with resources attached.
After initializing the Mac features, the program enters the event loop. This loop
detects when an event has occurred (GETNEXTEVENT), processes the event, and then
returns for the next event in the queue. The loop decodes the event using the select case
statement with the "what" portion of the event record. The mouse down event is of
primary importance because it locates where the mouse button was clicked using
FINDWINDOW. The mouse down event is decoded using if-then-else constructs. Menu
events are passed to the subroutine "menus" for decoding. This subroutine decodes the
menu item choosen using select case constructs.
The only portion of the program design given in Listing 1 that caused serious
exploration of Inside Macintosh and the MacFortran manual for an answer was the
modal dialog box in the About menu choice. Modal dialogs force the user to respond to
the dialog by "locking" out all other interfaces (menus, etc.). Calling a modal dialog
defined in the resource fork would be done in MacFortran by:
dlg=toolbx(GETNEWDIALOG,dlgid,dstorage,behind)
call toolbx(SETPORT,dlg)
call toolbx(MODALDIALOG,userfilt, itemh)
call toolbx(DISPOSEDIALOG,dlg)
where dlg is a pointer to the dialog structure, dstorage is set to 0 to allocate the
storage on the heap, behind is set -1 to bring the dialog to the front of the windows on
the screen, itemh is the item number clicked on by the user, and userfilt is a pointer
to the starting address of the user supplied filter function. The user controls the
events on the screen during the modal dialog with the filter function (see Bob Denny's
C Workshop Volume 1, # 7 for an example).
No Filter Functions in MacFortran
The problem with implementing this structure in MacFortran is that there
currently is no easy or reliable way to get the handle to the user filter function,
userfilt. Absoft states that they are working on a fix for this problem. However, in
the mean time, users cannot write their own custom modal dialog boxes. I will report
any solution as soon I discover one. Note that this problem does not exist for modeless
dialog boxes. For an example of a modeless dialog used for the About menu option, see
Dave Smith's Assembly Lab (Vol. 1, #4).
Instead of using a modeless dialog for the About menu, I elected to stay with a
modal dialog, but use a simple control button from a dialog resource to exit the dialog
box.
Creating the Standalone Application
Compiling and linking the resources should proceed in the following manner.
First compile the application source code using the Macfortran compiler. Next, if you
want to create standalone code, use the MacFortran linker to link the output of the
compiler with toolbx.sub and f77.rl, the run time support package. After linking, then
compile your resource file with Rmaker, and use an include statement in your
resource file to move in the linked fortran code file. If you compile and link the
resources using Rmaker before linking the runtime package, the MacFortran linker
will get lost. So compile, then link, then run Rmaker! The result will be a stand alone
Referenced by (2):