Problem with Fortran compiler not recognizing routines used previously

[ivf_ian]

Having problems with the Fortran compiler not recognizing certain routines which had been previously used in the program, more specifically, createwindowex. loadicon and loadmenu.  See drop box.  What happened to them and are there other routines one could use instead?   

[andrew_4619]

Simple. It is looking for a loadmenu interface that matches what you have asked for. I am guessing the ghmodule is integer(4) and  not integer(handle).  In x64 both inputs to loadmenu will be integer(8) but you are supplying an integer(4) and an integer(8) and it is looking for a interface that matches that which does not exist!

[ivf_ian]

Thanks.  Got rid of one of the NULL and IDI_APPLICATION errors, but unsure how to deal with CmnDlgMenu.  I have included screen dumps to show the files involved.

[andrew_4619]

go back and read my last comment more carefully you did not fix it.

then to understand better:

google "MSDN LoadMenu" that tells you about that function and what types are used.

At the bottom of that page you will see this is in "User32.lib". If you go to the folder you found IFWINTY.f90 you will  find USER32.f90, and if you open and find LoadMenu you will see the interface and how the items are declared in Fortran.

For the record in X86 the variables in your screen grab ::  ghmodule, hmenu,  hchildmenu,  hmenuwindow are all 8 byte 'handles'. 

[GVautier]

"For the record in X86 the variables in your screen grab :: ghmodule, hmenu, hchildmenu, hmenuwindow are all 8 byte 'handles'. "

Are you sure? 

[andrew_4619]

Yes, but it easy enough to check by looking at those sdk routines on msdn

[danielbrown8998 · Accepted solution]

The issue happens because CreateWindowEx, LoadIcon, and LoadMenu are Windows API functions, not built-in Fortran routines. If the compiler can’t recognize them, it usually means the Windows API libraries or interfaces are not linked/included.

Possible reasons:

Missing Windows API interface/module.

Required libraries (like user32) are not linked.

Compiler update removed old compatibility modules.

Fix:

Link the user32 library when compiling.

Include the proper Win32 API interface in your Fortran code.

Alternative:
You can also use GUI libraries such as GTK for Fortran instead of calling the Windows API directly.

[ivf_ian]

I have inserted the line user32 within the win_intr module.  See drop box.  Is that correct?

How do I include Win32 API interface in my Fortran code?

[Steve_Lionel]

You've done that with the USE line, but only for the parts of the Windows API that come from user32.lib. If you want access to the entire Windows API (at least the part for which the Intel modules define interfaces - I don't think this has been updated in ten years), put in "use ifwim" instead.

[ivf_ian]

Thanks, but I couldn't find the ifwim module in any of the directories on my computer.

[Steve_Lionel]

Sorry, typo. I meant ifwin.

[ivf_ian]

Thanks for the clarification.  While I can find createwindowex routine in user.f90, where might I find createwindow.  

[Steve_Lionel]

It's defined in module IFWBASE - probably because there isn't an actual Win32 API function named that, but rather a macro (in C, as supplied by Microsoft.) In Intel Fortran, CreateWindow is implemented by a wrapper function that comes from ifwin.lib.

[ivf_ian]

Thanks - extremely useful.  Not sure why all the relevant content is scattered all over the place – very inconvenient.

A colleague of mine developed the code for interfacing my Fortran program with Visual Studio two decades ago, which worked well upto this recent version of Visual Studio.  Like others, and as you can guess from the forum exchanges, I am discovering numerous issues preventing successful operation of my code.  However, I am trying to familiarize myself with the code my colleague developed and feel I am making progress, albeit slowly.  Next question is regarding parameters she used, which I don’t believed she defined, but obtained from files like the one you suggested for the createwindows, ifwbase.f90.  Where is WM_SETFONT defined and what is the significance of MAKELONG(TRUE,1) in this sendmessage call.  See drop box.  There is no other mention of MAKELONG parameter anywhere else in the program.  Also there are other parameter types such as T_TEXTMETRIC, STATUS, TOOLS, etc., which I can’t seem to find defined within my program.

[Steve_Lionel]

WM_SETFONT (as well as T_TEXTMETRIC) is defined in module IFWINTY, which is implicitly included when you USE any of the other Windows API modules. MAKELONG is another one of those things that were initially a C macro and is provided by IFWBASE.

Hint: If you want to know where something is defined, use a file search tool (or even Visual Studio) to search the .f90 files in "C:\Program Files (x86)\Intel\oneAPI\compiler\latest\opt\compiler\include" for the thing you want.

STATUS and TOOLS are a bit too generic and are probably declared somewhere in your sources.

[Steve_Lionel]

As for why things are in various modules - they're largely organized by which Windows API .lib they come from, as documented in the MSDN library description of the function. Types and PARAMETER constants are generally in IFWINTY, except for some recently created modules I wrote such as module PSAPI. See Domestic or Imported? - Doctor Fortran for more on this.  If everything was packed into one large module it would dramatically slow down compile time. This way you can be more selective.

[ivf_ian]

Thanks.  That was very helpful.  However, I still am confused re. whether or not to define parameters and where they should be located

The screen dump in drop box shows the compilation process, giving the 1st warning (ghwndmain) in the osda.f90 routine. 

For convenience I decided to remove a large chunk of my program and just concentrate on a few files and try to eliminate errors/warnings in a systematic manner.

I am developing the program as a windows app rather than a console one and I know that linking the few files included will not allow that, but I’m working on sorting out the compile issues.  Also included in the drop box is a zip file containing the files currently included in the project.  Appreciate your help.

[Steve_Lionel]

I'm looking at your sources, and in some of the files I see correct declarations of, say, ghwndmain, commented out, leaving them implicitly declared as the wrong type. You have "integer(handle)" a lot, but not for some of these handles and where you do have them, they are usually commented out. In the case of hinst, you have it just declared as default integer rather than integer(handle). 

There are also a bunch of handle variables (typically starting with "h") in Dia_intr.inc that are not declared as integer(handle) but should be. I also saw some errors about variable HPEN whose declaration is commented out in Plot.inc, so it ends up as a default real scalar instead of a integer(handle) array as the code wants.

[andrew_4619]

Those are just the tip of the iceberg. Derived types with bad handle types, lots of vars passed as message parameters with wrong types, IMPLICIT variables, ...  Quite a bigish job for someone who knows what they are doing.....  

[ivf_ian]

Apologies for the mess, but what I have been trying to do is experiment with integer(handle) replacing integer.  The code used for interfacing was developed by a young colleague 20+ years ago and my program actually ran very well until recently when I guess 32 bits were replaced with 64 bits.  I have made quite a bit of progress, but am kind of stuck on this ghwndmain parameter.  I am aware there are a number of integer definitions within dia_intr.inc, which perhaps should be integer(handle), but that shouldn’t affect ghwndmain, should it not?.  It seems whether I define ghwndmain as integer(handle) in win_intr.f90 or not, I still have a problem with it.  For the record when I carry out a compilation, I first clean, then compile win_intr, then tools and finally osda.   Any ideas what might me causing the problem?

[ivf_ian]

I had thought that by restricting the size of the program, it would easier to find out and correct the problems, but now I see that was probably a mistake.  I am now working on the complete program, which I have zipped and placed in drop box.  I have also included the compilation and as you can see it objects at line 86 of osd_c.f90 – not sure why. The zipped program is exactly that which runs successfully on the later Intel Visual Fortran, apart from the modifications in dia_intr.inc which you suggested in your latest correspondence and a number of modifications within win_intr.f90, although not sure whether what I’ve done is correct.

Once again apologies for making things actually more confusing by not including the entire code to start with.