Fax: +44(0)1865 300 232
This document answers some of the most frequently asked questions from potential purchasers of Winteracter, the Fortran 9x GUI toolset.
(Please note this is not a technical FAQ. Winteracter includes an extensive technical FAQ in its on-line help file.)
Fundamental Product Features
Language / Calling Interface
Winteracter uses the native menu/window/dialog handling features provided by the Windows API to ensure a 'standard' look & feel. The Linux version uses Xlib and the well established Motif interface, to achieve a close equivalent.
From Winteracter's inception we were committed to providing visual tools to simplify the design and development process. One of Winteracter's core tools is the resource editor, which is used to create and mantain your application's menus, dialogs, toolbars, icons, bitmap-buttons and cursors. This allows you to design and edit your main user interface components without writing a single line of code. You also get full control over the layout of your dialogs, instead of having to second guess complex auto-layout algorithms. Some products rely heavily on out dated concepts of interface design, based largely on subroutine calls. This cumbersome model has been superseded in most non-Fortran products by the use of visual design aids. Winteracter delivers the same capability to the Fortran community.
Our commitment to a visual style of programming is on-going. The full set of Winteracter tools are detailed on the Visual Tools page.
Winteracter makes use of resource files which define dialog and menu layout. In addition they can contain other UI resources such as bitmaps, icons and cursors. This resource gets incorporated into your executable just like any other object file, using the resource compiler which is supplied with your Fortran 9x compiler (under Win32) or with Winteracter itself (under X Windows). The individual resources are then accessible in the calling Fortran program via simple numeric identifiers.
The resource file and the associated list of numeric identifiers are maintained automatically by Winteracter's resource editor. Developers need no knowledge of the resource script format.
Our resource based programming model is the key to our powerful visual design methodology. It clearly separates dialog/menu design from input handling. Good UI design is a development task, not something to be performed at run-time. A resource based programming model makes this possible. What's more, changes to menu and dialog layout can be made and viewed in our resource editor and saved as updated resource files with no need for Fortran source recompilation.
"But I've read that resources run out very quickly. Won't Winteracter programs use up all my Windows resources?" Certainly not! This fails to understand how resources work. For example, under Windows, the resources built into an executable don't use any of the memory reserved by Windows for resource usage until explicitly requested. Winteracter allows you to load and unload dialogs, etc as needed. It's up to you how many dialogs you load simultaneously. In reality, a Winteracter program uses no more system resources than development systems which use 'on-the-fly' resource creation.
Another benefit of using resource files to define your user interface layout, rather than subroutine calls, is the ability of our resource editor to reload and edit those layouts throughout the development cycle. Visual tools which generate Fortran source code to define the user interface cannot do this.
You will have one already! All the Win32 Fortran compilers supported by Winteracter are supplied with a resource compiler. X/Winteracter includes our own equivalent for use with Motif based applications.
Our business has always been about servicing the needs of Fortran programmers writing Fortran programs. Winteracter delivers just that : A totally Fortran based GUI solution. No mixed language programming is necessary, avoiding all the horrors of interfacing to C, C++, Delphi, Visual Basic, Java, etc.. Our aim is one language, one solution.
We took a decision early in Winteracter's development that it would be a Fortran 90 dedicated product. Given that INTERACTER was then some 7 years old and Fortran 77 was nearly 20 years old, we had to look ahead. In this context, launching a Fortran 77 product seemed unthinkable (even though many existing Fortran developers were still 77 based). There are now numerous Fortran 9x compilers in use on our target platforms. We therefore took a view that Fortran 9x was the only way to go. Our experience since the initial launch has been that this was the right move, with an ever increasing number of Fortran developers making the transition. Indeed, many developers have taken Winteracter as their cue to finally make the switch from Fortran 77 to Fortran 9x. Many others have welcomed our move to a standard they were already utilising.
By supporting Fortran 9x we are able to take advantage of features such as modules, free format source code, optional arguments, CASE constructs and much more. The WINTERACTER module in particular is a fundamental part of Winteracter programming, providing a full set of interface definitions (eliminating most argument passing errors) and meaningful parameter names. An extensive set of Fortran 9x Winteracter example programs are also provided.
Of course, simply because Winteracter requires a Fortran 9x compiler, this doesn't mean you can't reuse your old Fortran 77 code. The 9x standards include the whole of 77 as a subset, so there's never been a better time to move forward.
If you care about the readability and maintainability of your code, Winteracter must be high on your list. We believe our calling interface is simpler and cleaner than any competing Fortran based product. Winteracter uses meaningful names for all of its subroutines, instead of cryptic 6 character names. In addition, hundreds of meaningful parameter names are declared for subroutine argument values and function result codes. You can actually read a typical Winteracter program and get a pretty good idea of what's going on, without having used the product or written the program.
No it doesn't. Callbacks make program flow hard to follow. Instead we have implemented what we term 'semi modeless' dialogs. These appear modal to the user (i.e. the rest of the application is blocked out) but modeless to the application (i.e. the program retains full control over the user interface whilst the dialog is visible). Winteracter can also report when the user moves between fields in a dialog, allowing field-by-field validation without resorting to callback routines.
Winteracter's extensive graphics routines are derived from our long established INTERACTER product. This means that Winteracter's graphics are extensively tried and tested. It also means that they have been developed to a level of maturity way beyond just a few GDI line and fill interface routines. In addition to comprehensive device independent primitives, we also provide extensive higher level graph/chart, plotting and 3D modelling functions at no extra charge.
Fortran graphics programmers invariably need to get their results onto paper or into third party products like word-processors. As an industry we've managed to invent more ways of doing this than bears thinking about. Thankfully, I.S.S. has been addressing this problem for over a decade, so Winteracter not only supports Win32 API output to Print Manager and Windows metafiles, it also provides drivers for HP-GL, HP-GL/2, HP PCL, Epson ESC P and ESC P/2, PostScript, DXF, CGM, SVG, BMP, PCX and PNG formats. Bit image printer dumps are also supported. This way, whatever device you need to print on or whatever package you need to export to, chances are we provide a solution which genuinely works. Also, remember that you get all these drivers as standard with Winteracter.
Winteracter includes a full emulation of the old CalComp HCBS interface (1977 spec), supplied in source code form. Also included is an emulation of Lahey's Video Graphics Library as supplied with F77L, F77L-EM/32 and early versions of LF90. As an added bonus the emulation also supports a substantial subset of Lahey's add-on Graphoria product.
We support both PNG (Portable Network Graphics) and SVG (Scalable Vector Graphics). PNG provides compression on a par with the GIF format, is not subject to licencing limitations and supports 24-bit colour. Winteracter can load and save PNG files at a variety of colour depths. SVG is the web vector graphics format defined by W3C. We have chosen not to support GIF (which is encumbered by royalty/patent restrictions and does not support 24-bit colour) or JPEG (lossy and therefore poorly suited to scientific graphics).
Yes. The Linux version is based on X Windows and the Motif toolkit. Known as X/Winteracter, this version provides a high degree of compatibility with the Windows implementation. Both 32-bit and 64-bit Linux platforms are supported.
Yes. The X Windows version has also been ported to Mac OS X. This relies on the X11 X server which Apple ship with Mac OS X, along with versions of Open Motif are downloadable from the net (details are provided with the X/Winteracter documentation).
Both PowerPC and Intel based Mac systems are supported, though support for Mac OS X/PPC has now been frozen. All future updates for Mac OS X will be for-Intel based Mac systems.
The only non-Intel platform currently supported is the Apple Mac running on PowerPC. This version has been frozen at v7.10a.
Support for other non-Intel platforms was frozen at Winteracter v3.10.
As of v2.30 (May 2000) we no longer guarantee support for Windows 3.xx. Winteracter based applications may still work with Windows 3.xx, but this is now an unsupported feature. Winteracter requires a true Win32 operating system, based on Windows v4 or later, i.e. one of the Windows 9x (95/98/Me) or NT (NT4/2000/XP) series.
The Windows version of Winteracter includes support for all of LF90 v4.x, Elf90 4.0 and LF95 5.x/7.x, in a single licence. LF90 3.50 is no longer supported. If you are still using LF90 3.x or earlier, we recommend an upgrade to a newer compiler. The Linux version requires Lahey Fortran 6.2 (Linux/x86) or 8.0 (Linux/x86_64). Any of the Express, Standard or Pro variants of LF95 are suitable. The Lahey "Fortran" for .NET compiler is not supported for several reasons, primarily because it does not compile standard Fortran.
The Lahey Winteracter Starter Kit (WiSK) (as supplied with LF9x v4.0 onwards) includes plenty of functionality to allow you to create substantial Windows programs. However, if you decide that you want access to more Windows/graphics features then you might consider upgrading to the the full version of Winteracter.
The full version of Winteracter adds memory bitmap/metafile manipulation, toolbars/tooltips, tabbed dialogs, more dialog field types, spreadsheet input, built-in editor, range checking, Print Manager hardcopy interface, a more extensive range of graphics primitives, presentation graphics, 3D modelling, several graphics hardcopy/export drivers, more visual tools, operating system interface, etc.
As far as graphics are concerned, the difference between WiSK and Winteracter is the same as between LISK and INTERACTER. Winteracter's graphics routines are compatible with INTERACTER, as are the operating system, max/min and character handling routines. The WiSK and LISK subsets are the same in these respects as well.
The Lahey version of Winteracter for Windows includes support for both LF90 and LF95. Users upgrading their v1.xx LF90 Winteracter to the current version will receive both LF90 and LF95 libraries.
The LF90 Winteracter library can also be called from programs compiled with Elf90, since both compilers are based on the same technology. Virtually all of the supplied example programs use Elf90 compatible syntax. Our development environment (WiDE) is also Elf90-aware. Version 4 of the compiler is required.
In general, we support all versions of LF95, but it is worth noting the following:
Yes. Winteracter has supported Visual Fortran ever since the release of both products in early 1997. It is surprising how often this question comes up, The confusion appears to arise from the various different owners of the Visual Fortran product (first Digital, then Compaq, now partly HP and partly Intel). We refer to "Visual Fortran" both on this site and in our documentation for the sake of brevity, instead of "Digital/Compaq Visual Fortran". Note also that Visual Fortran and Intel Fortran are currently entirely separate products, requiring different versions of Winteracter.
The DVF/CVF version of Winteracter will work with any version of Digital/Compaq Visual Fortran, i.e. all of 5.0 through 6.6. The same licence also includes support for the Win32/IA32 version of Intel Fortran 8.x/9.x ("Intel Visual Fortran"). (Note: As of Winteracter 6.0, we no longer support the Intel Fortran 7 compiler).
From Winteracter v7.0 onwards, Intel Visual Fortran is also supported on Windows X64 operating systems running on AMD64/EM64T compatible processors. This Win64 version is supplied separately from the Win32 DVF/CVF/IVF compatible version.
We operate a Winteracter technical support service via email. Registered users may submit bug reports and other Winteracter related enquiries to this service. Please use email to submit support enquiries, since this allows rapid and efficient exchange of supporting material and solutions.
Winteracter includes all visual tools and hardcopy export drivers as standard. So you don't need to buy Visual Basic, for example. Also, there are no run-time fees or royalty payments.
Note: If you intend to build help files in either of Microsoft's Windows Help (HLP) or HTML Help (CHM) formats, via HelpEd or Help2HTM, then you will need the corresponding Microsoft help compiler. In the case of the Windows Help (HLP) format, the corresponding Help Workshop is included with recent versions of the Lahey, Compaq and Absoft Fortran compilers.
While developers may find that certain Winteracter features work with some 3rd party GUI tools or APIs, we are unable to provide advice or support on the use of these programming interfaces. We don't have any control over their behaviour. They may well perform message/event processing which interferes with Winteracter's normal operation. The use of such tools is therefore likely to be counter-productive.
The primary motivation was the 'look and feel' issue. Many customers were demanding a truly Windows like appearance. More recently we have encountered demand for similar functionality under X Windows (particularly on Linux). Portability and backwards compatibility issues precluded such a development within INTERACTER, which employs a character mode interface, even on graphics displays.
Instead, we decided to take all those parts of INTERACTER which we could reuse (notably our tried & trusted graphics and operating system interface) and incorporate them in a new product. The user interface elements of Winteracter (menus, dialogs, etc.) were therefore redesigned to match the structure of the Windows environment while retaining much of the simplicity and style of programming interface which made INTERACTER popular. The dialog management routines in particular bear a notable resemblance to parts of the INTERACTER Forms Manager. Winteracter also includes a tool (IFD2DLG) which converts INTERACTER forms to Winteracter dialogs.
INTERACTER development ceased in 2000. Technical support was withdrawn in August 2006. Selected versions remain available on a strictly unsupported basis. We recommend Winteracter for new development.
Any INTERACTER graphics code can be used virtually without modification. The only change likely to be required is the introduction of a USE WINTERACTER statement at the start of each program unit which calls our graphics routines. Similarly code which calls routines in our OS (operating system), CH (character handling) and MM (max/min) subroutine groups can also be reused.
Code which uses INTERACTER's Forms Manager will require some modification, notably the conversion of forms to Windows dialogs. However, we provide a tool (IFD2DLG) which will do this automatically. Many of INTERACTER's Forms Manager routines have direct equivalents in Winteracter too, notably the field assignment/retrieval routines. The function of the INTERACTER form designer INTFORM is replaced by the dialog editor, which forms part of the resource editor.
Text screen output via the INTERACTER window manager will need to be reimplemented using the WM (Window Management) and GT (Graphics Text) routines. The ED (Text Editor) subroutine will also prove useful when upgrading such code.
Input handling probably requires the most code redesign. Winteracter programs operate around a message delivery routine, normally located inside a DO loop. All keyboard, mouse, menu and dialog events are reported through this mechanism. The number of possible message types which must be processed in Winteracter programs is vastly reduced compared to a 'raw' Windows API or Motif program, however.
Menus are handled somewhat differently to INTERACTER and are designed externally using the resource editor. As noted earlier, menu selections are returned via the message reporting mechanism.
INTERACTER was upgraded to use a modern long-name calling interface in 1994. Legacy codes which still use the early 6-name calling interface can be upgraded using the TOLONG tool which ships with both INTERACTER and Winteracter.