Fortran and Windows
Fortran and Windows
Each of the current generation of commercial Fortran compilers (Silverfrost, Intel, Lahey and Absoft) is supplied with tools for building simple Windows applications.
The Intel compiler comes with QuickWin. This allows you to route output to the screen, and to create simple menus and dialogs. Absoft's compiler includes an application framework called MRWE, which has a similar functionality; MRWE is also available in Absoft's Mac compilers. Lahey's LF90 is supplied with a cut-down version of Winteracter, the Windows toolkit described in more detail below. Salford's ClearWin+ is an ambitious attempt to make Windows programming easy for Fortran (as well as C and C++) programmers. Unusually, the interface is specified using something rather like a FORMAT statement and is very powerful, allowing the programmer to build fully-fledged Windows applications. However, many prefer a more visual approach to interface design.
In addition all these compilers allow you to call Windows API functions, and all now provide modules which specify Windows constants, structures and prototypes.
- To go beyond the facilities offered by the compiler, you should look at one of the third party Windows development packages.
Winteracter provides dialog and menu editors to help you define the user interface to your application. For each control, these utilities define identifiers, which are used in a message loop to attach responses to user actions. Winteracter also includes a comprehensive graphics library which includes graphical input, output and hardcopy primitives, presentation graphics routines and contour and surface plotting routines. Versions of Winteracter are available for all these compilers. It's worth noting that if you want cross-platform support, versions of Winteracter also exist for Linux - you'd have to buy a new Winteracter license to go with your Linux compiler, but that's got to be a whole lot cheaper than the time to rewrite the interface.
GINOMENU is on the surface very similar to Winteracter, but its drag-and-drop designer (GINOMENU Studio) is more complete as it is used for not only defining the user interface but also lets you associate the event-handling code with each control. Its code editor includes Fortran syntax highlighting and is code-aware of all the routines available in the GINO graphics libraries providing context-sensitive help and code-assist pop-ups for all the arguments. The whole application is wrapped up into a binary project file and instead of creating a resource file that is linked into the application, like Winteracter, GINOMENU Studio creates one big Fortran source file that contains both the user-interface code and the user-code. This can be quite cumbersome for large projects with the default code block containing one big message loop controlling the events, but user-code can be contained in smaller subroutines and these can contain individual message loops if desired.
Unlike Winteracter, it is only available under Windows and if you require 2D or 3D graphics functions, the full version is quite a bit more expensive.DISLIN is another alternative which is available for a wide range of systems and compilers, and is free for non-commercial use. It's a more traditional graphics and GUI library - there's no way to define dialogs visually.
- Another approach is to use VB.NET, C#.NET or Delphi to create a user interface, and move your Fortran code to a computational DLL (dynamic link library). This route gives you access to a superb user interface builder, and to ALL of the facilities of Windows, including for example, databases and third party ActiveX controls. However, the learning curve can be quite steep - obviously, you have to learn another language. Depending on how your program is organized, conversion to a DLL may involve a lot of restructuring. The main problems are:-
- The computational and user interface sections must be rigorously separated. A new VB/Delphi backbone which contains almost all user interaction must be transplanted into your program. In many real world programs, you will require a second DLL (possibly written using Delphi) which provides some modal I/O functions for the Fortran (a modal function is one which must complete before any other action is started). In effect the Fortran DLL forms the filling of a Delphi sandwich.
- All STOP statements must be eliminated. For example, a Fortran program may have an error reporting routine which prints a message and then halts execution. In a DLL, control must be passed all the way back up the call tree to the VB/Delphi backbone. If extensive use is made of the error reporting routine, this can be a daunting exercise.
- Initialized data is not re-initialized at each entry to the DLL. For example, if you have a counter which is initialized, using a DATA statement, to zero, and then incremented within the program, you must bear in mind that the counter will not be re-initialized when the code is invoked a second or third time.
Despite the problems, there are situations when the DLL route is best, most notably where a specialised look-and-feel is all-important and you simply can't compromise on, for instance, having oval shaped buttons. However, in some cases, you can use VB or Delphi as a front end without converting your program to a DLL; instead, the program remains as a standard Win32 command mode executable which is invoked and run invisibly from the front end. This is most appropriate when there is just one entry to the program, typically via a "Start" button. This solution avoids the problems with STOPs and data initialization, though the separation of computational and user interface code remains. There are various mechanisms for passing data and messages between the front-end and the computational program.
So, money on the table time - which metho