Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Calling MFC dialogues from a Console based Fortran Applicaiton.

ayazahmed99
Beginner
381 Views
Hi,

I am developing a GUI, around a Fortran application.

Acutually, the original console based Fortran application:

- reads the input string data from external ASCII files,
- processes the input data and
- writes back the processed string data to different output ASCII files.

For developing a GUI, I wanted to have an expert opinion on the following choices:

(a) If I create a console based Fortran application and call MFC dialogues, from the console based Fortran application. The MFC dialogues supposed to locate the input ASCII files (e.g. with the help of MFC file selection Dialogue) the C++ reads the string records of the ASCII files. This read data is sent back from C++ to Fortran side, for processing (At the Fortran side the processing routines are already defined). The output of the application (string data) is written back to the output ASCII file via Fortran routines, directly.

(b) If I create MFC dialogues around a Fortran application. Those MFC dialogues are solely responsible for I/O and only the computation routines are defined in the Fortran side.

Could any body answer the following:

- Which approach is better?

- In case of choice (a), can I call MFC dialogues e.g. InitInstance() method to launch a dialog boxe (which takes input data (record from the selected file name) and bring it back to the Fortran side.

- I have read in this forum that the multiple IO (in different languages)is a bad choice, May I ask why?

- In case of chaoce (a), MFC is the right choice for developing dialogues or I have to switch to Win32 APIs?

Regards,

Ayaz
0 Kudos
4 Replies
isn-removed200637
381 Views
It sounds like you are first and foremost a C++ programmer?
If that is so, I can see why you want to do the GUI using C++. You will need a FORTRAN compiler to create a DLL containing your FORTRAN processing engine.
Do you have Compaq Visual Fortran? If so, then it is easy to create your own dialogs and use GETOPENFILENAME and GETSAVEFILENAME functions to give you
access to common Windows dialogs for selecting files for opening and saving. This way you can do the whole thing in FORTRAN without having to worry about argument and
name handling to pass strings between C++ and the FORTRAN DLL you would otherwise require.
Stick with it and you will
discover that there is plenty of help available here on your topic, just do a search in the forum for GETOPENFILENAME etc. HTH

0 Kudos
Jugoslav_Dujic
Valued Contributor II
381 Views
The answer really depends on what environment (C++ or Fortran) you're more familiar with and feel more comfortable. A "classic" solution for building GUIs is to have the main application written in some RAD tool such as VB, Delphi or MFC calling fortran console application or, better, dll. Of course, it's possible to build an all-Fortran solution, either using APIs directly or by calling wrappers such a DFLOGM.

I don't think your solution a) is even possible -- MFC is a framework and you can't (at least not easily) call bits&pieces of it from another application -- the main program must be MFC so that the program can be properly initialized.

If really all you need is to invoke File open/save dialogs, it's probably best to use an all-Fortran solution calling GetOpenFileName API (I've written a wrapper more convenient to use which you can find here). If you need more than that, use whatever language you find suitable to build a GUI and call the Fortran as a console application or, better, make a dll out of it. You'll find a bunch of info in CVF chapter on mixed-language programming, as well as on this Forum -- I'd estimate that about a quarter of threads is related with mixed-language programming.

Jugoslav
0 Kudos
ayazahmed99
Beginner
381 Views
Hi,

Many Thanks Anthony and Jugoslav for your help.

I am using the Intel Fortran compiler 7.1 and MS Visual studio .NET (Sorry, I should have mentioned this beofore).

Jugoslav!

I tried XFT Library with these tools. Even for creating XFT.lib, I got endless compile time syntax errors, mainly in "XFTAPITY Module", due to the syntax declearation of type:

"INTEGER, PARAMETER:: MF_INSERT = #00000000"

Could you please tell me what am I doing wrong?

I read in the Intel documentation (Porting Applications from Compaq Visual Fortran to Intel Fortran) that DFLOGM is not supported by the Intel Fortran compiler, and I could see that, you have used the DFLOGM, in the XFT. Is this the reason for the compile time errors?

Ayaz
0 Kudos
Jugoslav_Dujic
Valued Contributor II
381 Views
Ayaz, I referred more to XFT Lite version (XFTlite.zip containing XFTGDI and XFTFILE) which is tested & documented; XFT full version on the site is in rather disheveled state and provided more for the ones feeling adventurous :-). [Tested & documented version is coming Real Soon Now :-)]

I'm not positive whether files from XFTlite will compile with Intel Fortran as-is, since it does not support all CVF extensions as yet. #00000000 is non-standard form of hexadecimal constants -- Z'00000000' is the standard form (I'll change that). XFT* modules itself do not use DFLOGM -- it's used only in the sample application. Note that, even in XFTLite, there is a IF (DF_VERSION) block which declares APIs absent from earlier CVF version -- I really can't tell in advance whether it will need to be adjusted for IF.

Feel free to send me an e-mail if you encounter more problems -- I'd certainly like to make it work for IF as well, but I don't really have enough resources.

Jugoslav
0 Kudos
Reply