Reference Material for Visual Fortran Windowing Applications

[Jamal_S_]

Hello,

I am attempting to create a simple windowing application in Fortran using Visual Studio.  I have experience with C and BASIC, but I am completely new to Fortran.  In order to create my application, I have started off by attempting to reverse engineer the sample SDI code, and so far it has done a great deal to familiarize me with the nuances of this language.

However, I am still having trouble understanding what some of the code exactly does, and I cannot seem to find references that cover Fortran windowing applications.  I was wondering if anyone could link me with helpful references that I could use to look up these things.

Thanks,

JS

[Steven_L_Intel1]

• Using Intel® Visual Fortran to Create and Build Windows*-Based Applications (includes QuickWin)

This will help somewhat, but if you really need to understand what the code does, assuming it calls Windows API routines you'll need to look at the MSDN Library.

[Jamal_S_]

Hello Steve,

Thank you for the prompt response, the program does indeed call Windows API routines so I will have to look at the MSDN library.  Now that I have discovered this forum, I will certainly be back as I run into more questions.

Best regards,

Jamal

[Steven_L_Intel1]

An old but still useful reference is the book "Compaq Visual Fortran: A Guide to Creating Windows Applications" by Norman Lawrence. Unfortunately getting copies of this book can be costly, as I don't think it's being printed anymore.

The users in this forum are a great resource for help with such issues.

[Paul_Curtis]

Forget the Lawrence book, it's poorly written and conveys exactly nothing of the essential structural features of Windows programming.

My suggestion is to do what about 99% of all Windows programmers have done, which is to get one of Charles Petzold's books from about 10 yrs ago (before he sold out to MFC), read it carefully and work through the examples.  Petzold's code is all in C but you can easily translate on the fly to Fortran, and IVF provides interfaces to all the WinAPI functions.  Petzold provides not only the low-level mechanics, but also the organizational overview of how Windows works.  Result: it is very straightforward to write complete WinAPI programs, do anything possible in Windows, entirely in Fortran.  (Caveat: learning WinAPI programming is not necessarily easy; took me most of a year to become really effective.)

[Jamal_S_]

Steve and Paul,

I appreciate both of your responses, even though they do not agree with each other.  Now I know of multiple good places to learn Windows programming in Fortran.  I have to admit that Paul has me quite sold on the Petzold book, but I will look at both the Lawrence and Petzold books regardless.  

I can see that this is a very supportive community, and I hope that I can get to the level where I am on the giving end rather than the receiving end of it.

[dboggs]

Another possibility you should at least consider is to use the Quickwin type project that is part of your Intel Fortran package. Some users of this forum will groan at this suggestion but there are at least a few who use it. Depending on your needs, and how familiar or lack thereof you may be with Windows API programming, the Quickwin approach may be far, far easier than the API approach. Typically you can do in about 5 statements what requires 50 statements in API. But of course along with this ease of use comes lack of control to do many things.

Quickwin is also covered in the Norman Lawrence book, the bulk of which deals with API. It's very out of date as Steve suggested, and in places poorly written as Paul suggested (I find the API portion to be completely flabbergastering), but it's how I got started and I found it very valuable.

[FortranFan]

Based on what you mentioned in your original post, " I have experience with C and BASIC, but I am completely new to Fortran, " I would also suggest you take a look at Microsoft .NET with C# and Visual Basic options.  There is a world of richness that can open up for you in the .NET platform leading toward an eventual ease-of-use in web-based applications (HTML5/ASP.NET) and/or Windows mobile and/.or Android (long-run) for the solutions you develop.

Note you can have Fortran very much in the mix, if that is what you really need, with enhanced interoperability features available in modern Fortran that can form the basis of a mixed-language, mixed-mode solution.  It is possible without too much difficulty (of course, that is subject somewhat to personal biases and open to some interpretation!) to integrate Fortran code and libraries and data in an development framework that gets most visibility now from Microsoft itself.

[Greg_T_]

With experience in C you could consider writing the GUI in C# which then calls Fortran routines to do the computations.  We have had very good success with our fracture mechanics analysis software with a mixed language approach that has a C# GUI which then calls Fortran routines in a group of DLLs.  Our program's ratio is the one C# executable and 15 big Fortran DLLs that do the engineering calculations.  The big advantages for us have been the fast speed of the engineering calculations in Fortran, and the longevity or long "shelf-life" of the Fortran code, some of which has been working for years.  The mixed language approach has also helped us enforce the separation of the GUI from the calculations, making the code very modular.

Regards,
Greg Thorwald

[dboggs]

Jamal, I think you need to clarify whether you are in need of a "windowing application" as you originally stated, or whether you also desire a "GUI interface" as some of us have assumed. There is a huge difference. For example, a windowing application cannot be separated from the rest of the code, and you will have to resort to either a simple yet half-baked approach such as Quickwin application, or a complete yet complex approach such as a Windows API application. If you really need a good GUI, then that can be logically separated, leaving the total package more "modular" and--at least in some cases--easier to maintain, upgrade, etc. If you don't want to go down the whole mixed-mode programming route (some might say rabbit hole) you might try looking at a special dedicated library for this purpose, such as Winteracter, which is designed to be called directly and easily by in-line Fortran calls.

Some windowing applications still look very much like traditional Fortran except for the fact that various "views" of the program's activity can be seen together on a monitor, e.g. a console window to interact with the user in the traditional style along with one or more output windows to show whats happening, intermediate or final results, and so on.

Failure to distinguish between a windowing application and a GUI interface is one reason you are getting a wide variety of feedback on this forum.

[FortranFan]

It is becoming increasingly easier to develop Window GUI applications using .NET (say with C# or Visual Basic) and the thing to keep in mind is the ecosystem is thriving; there is so much help available to guide you every step of the way, especially in cyberspace.  On the Tiobe Index, C# and Visual Basic are generally in the top 5 to 8 popular programming options universally, so skills learnt here can come in handy generally.

[Paul_Curtis]

Well, we all get to beat our little drums here.  Based (in part) on the stats of postings in this forum, any sort of mixed-language coding, let alone attempts to implement (non-Fortran) hideously complex OO concepts such as automatic inheritance of allocated pointer arrays in derived types or similar, causes IVF to crash and burn, and the suggestions that the OP use .NET or C#/VB for GUI would have him skate out on very thin ice indeed.  But the wonderfulness is that there is absolutely no need for any of that, it is very straightforward to do anything possible in Windows, directly from IVF and completely without mixed-language codes other than the supplied IVF interfaces to the WinAPI functions.  I have never understood why Intel does not aggressively promote IVF as a fully-capable Windows platform (the product is called "Visual" for a reason), sort of implies an opinion on their part that Fortran programmers are incapable of evolving.

[FortranFan]

Paul Curtis wrote:

Well, we all get to beat our little drums here.  Based (in part) on the stats of postings in this forum, any sort of mixed-language coding, let alone attempts to implement (non-Fortran) hideously complex OO concepts such as automatic inheritance of allocated pointer arrays in derived types or similar, causes IVF to crash and burn, and the suggestions that the OP use .NET or C#/VB for GUI would have him skate out on very thin ice indeed.  But the wonderfulness is that there is absolutely no need for any of that, it is very straightforward to do anything possible in Windows, directly from IVF and completely without mixed-language codes other than the supplied IVF interfaces to the WinAPI functions.  I have never understood why Intel does not aggressively promote IVF as a fully-capable Windows platform (the product is called "Visual" for a reason), sort of implies an opinion on their part that Fortran programmers are incapable of evolving.

These comments include statements that are plain wrong (there is nothing, absolutely nothing, with .NET that "causes IVF to crash and burn", for example), misleading (hideously complex OO concepts), and needlessly alarmist.  As to the latter, threads such as this one (probably the OP in that thread is the same as the one here) and Quote #23 by IanH show the value and relative ease-of-use of mixed-language programming with Fortran and the use of standard Fortran constructs and benefits of isolating platform-specific interactions to few, small modules/functions.

The couple of us who have brought up .NET in this thread have done so in a "judge for yourself" manner, pointing to OP that here is an aspect that Microsoft has placed atop their recommended practices for Windows application development.  Given Microsoft's own communiques and investment and their enhancements with .NET-based technologies, my own personal opinion is it is utterly injudicious for anyone to ignore .NET.  That does not mean I want to bully and scare anyone into using it and putting down other approaches while doing so; I only want to gently point out things are not as difficult with .NET as some may want others to believe.

A suggestion for OP would be to go any Windows development forum (just an example, here is one) and ask the readers there what they recommend now for a windowing application on Windows OS.  See if that is a) .NET or b) using Windows API and so forth (which may also include the use of COM-based dialog and ActiveX controls)  See how many suggest b) and if that is a sizeable population, go ahead and settle on b) 

I personally have experience with both a) and b) and I now see the benefits of .NET, especially keeping the future in mind the cloudy BYOD world that is coming i.e., web/mobile/tablet arena.  It is also borne out by the fact that many of my major software vendor partners have moved to .NET and WPF for their presentation layers and that on the Tiobe Index for popular options for programming community globally, Microsoft's .NET languages of C# and Visual Basic are in top 8:

Regardless, my suggestion to OP and everyone else is always along these lines: "take a look", study and review for yourself vis-a-vis any other approach(es) you may be considering, and only adopt if it suits you.  As I said in my first post, my other motivation was it all seems to build on OP's background, " I have experience with C and BASIC, but I am completely new to Fortran" 

[gib]

OK, I'll bite.  This kind of decision always depends on what kind of program you want to develop, but to get access to very powerful GUI functions I don't think you can do any better than Qt.  This is is C++, which does imply learning some new skills, but in my experience the comprehensive documentation and excellent IDE (Qt Creator) makes the process about as painless as it could be.  I'll go further, and say that it can even be fun.  Qt is free and runs everywhere.  As has been pointed out, with the C interoperability in Fortran, combining C/C++ and Fortran is now very easy.  My approach is to make the Qt/C++ side the main program, calling Fortran subroutines built as a DLL. It is relatively straightforward to link VTK libraries, providing an easy path to 3D rendering.