Resolving LOC(Routine) to Subroutine Call (Porting woes #1)

I'm porting my Xeffort GUI library (www.xeffort.com) from Visual Fortran to FTN95 (among other compilers). The code uses a lot of 'smart' non-standard tricks (since VF has pretty much full capabilites of C language) and I'm trying to find out how to find equivalent constructs in FTN95.

So, porting woe #1 is: the library contains a map of Windows messages (WM_WHATEVER) and user-registered handler routines (callbacks) for them. For each message, an address (LOC) of the handler routine is stored. When the routine is to be called by the library, it dereferences the pointer to the routine and calls it. In the original version, it used Cray pointers to routines (VF-specific). Later, I changed it to use VALUE/EXTERNAL mismatch, like:

[pre]

interface

MODULE XFTHandlerM

INTERFACE LOGICAL FUNCTION WM_CLOSE_Handler(fnHandler,xWnd) USE XFTTYPES INTEGER, INTENT(IN):: fnHandler !DEC$ATTRIBUTES VALUE:: fnHandler TYPE(X_WINDOW):: xWnd END FUNCTION END INTERFACE ... END MODULE XFTHandlerM

***implementation (external procedure 'driver') ***

!================================================= LOGICAL FUNCTION WM_CLOSE_Handler(fnHandler, xWnd) RESULT(bHandled) USE XFTTYPES LOGICAL, EXTERNAL:: fnHandler TYPE(X_WINDOW):: xWnd

bHandled = fnHandler(xWnd) END FUNCTION !=================================================

call

USE XFTHandlerM ... CASE(WM_CLOSE) bHandled = WM_CLOSE_Handler(lpfnHandler, xWnd)

[/pre] Notice the mismatch between 'interface' and 'implementation'. Alas, FTN95 does not appear to allow VALUE attribute for 'native' Fortran code 😦 .

So, what can I do? About the only think that comes to my mind is to use STDCALL declaration for the interface part, and F_STDCALL declaration for implementation part, but I'm not sure if linker will get it right. And I'd like to check out here before I start rewriting that part (cca. 100 interfaces and implementations)

Jugoslav

You may get an idea for what you need by looking at the supplied include file win322api.ins. You should certainly do some experiments on a small sample program before trying to change all of your calls.

I suspect that you may be the first to attempt to port to FTN95 from this environment. There are usually ways that these problems can be solved but, to be honest, they are probably not within the level of support that we can provide via a free forum.