cDEC$ compiler directives and missing alias

[isn-removed200637]

I am attempting to use the WIN API function GetMenuItemRect and, after looking at the INTERFACE for the function TrackPopUpMenu in DFWIN.F90, have added the following to my calling program:

    
	interface    
	logical(4) function  GetMenuItemRect(hWnd, hMenu , hItem, menrect)     
cDEC$ ATTRIBUTES STDCALL, ALIAS : '_GetMenuItemRect@16' :: GetMenuItemRect    
cDEC$ ATTRIBUTES REFERENCE :: menrect    
	use dfwinty    
	integer hWnd    
	integer hMenu    
	integer hitem    
	type (T_RECT) menrect    
	end function GetMenuItemRect    
	end interface    

and used the following call

    
	RETLOG=GetMenuItemRect(ghWnd,hMenu,2, dropdrect )

The routine compiles ok (with dropdrect defined as TYPE (T_RECT) ), but I keep getting the link error

    
OPENFILE.OBJ : error LNK2001: unresolved external symbol _GETMENUITEMRECT@16    
Release/generic.exe : fatal error LNK1120: 1 unresolved externals    

With the above interface block, the alias '_GetMenuItemRect@16' should ensure that the required routine is recognised. I know that TrackPopUpMenu has exactly similar interface(but with 7 arguments, hence @28 is appended to the alias '_TrackPopUpMenu' ) and it is found and linked ok and I know that both routines are
in USER32.DLL. It is frustrating that the linker is still refusing to find GetMenuItemRect !!

Please can you advise?

regards

tony richards

[Steven_L_Intel1]

You're using fixed-form source and the directive extends past column 72. While the FUNCTION statement would also appear to, it actually starts with a tab which counts as only one character.

Split up the directive into two (or more). You can't continue directives.

Steve

[isn-removed200637]

Many thanks, Steve, for spotting that. I completely ignored the possibility that
the directive was being ignored (or trested as a comment) because of it being too long. There was no warning to that effect. The FORTRAN statements go green if they are too long in fixed-format. I removed some of the blanks in the directive and everything now goes as planned.

[Steven_L_Intel1]

It's not that the directive was ignored, but that it was applied to the wrong name. The compiler doesn't complain, because you might have such directives for names you may or may not use. It is something that can bite you, though.

The easiest way to prevent such problems in the future is to use free-form source!

Steve

[Jugoslav_Dujic]

The easiest way to prevent such problems in the future is to use free-form source!

..which was the reason why I've missed it too -- what was the fixed-form source :-) ?

Jugoslav

[isn-removed200637]

The fixed-format code is listed in my post on compiler directives and 'missing' alias.
In case you missed it because of message board problems, here it is again:
(I will use courier font as the text is then spaced out as it is shown in FORTRAN)

  
  
	interface  
	logical(4) function GetMenuItemRect(hWnd, hMenu , hItem, menrect)   
cDEC$ ATTRIBUTES STDCALL, ALIAS : '_GetMenuItemRect@16' :: GetMenuItemRect  
cDEC$ ATTRIBUTES REFERENCE :: menrect  
	use dfwinty  
	integer hWnd  
	integer hMenu  
	integer hitem  
	type (T_RECT) menrect  
	end function GetMenuItemRect  
	end interface  

each record begins with a tab except the directives.
I got the first directive from DFWIN.F90 code hence it was ok for free-format code, but I
initially inserted it into a routine which was fixed format. I changed the leading '!' to 'c'.
When displayed in the DVF edit window, the FORTRAN code is displayed in blue in my case and
the compiler directives are treated as comments and listed in green. Note that the second line
beginning 'logical' actually displays as shorter than the following problem line.
It appears to be a peculiarity of the message board software that, when my sample code was
displayed there, the second line was displayed as longer than the first directive, hence
Steve L's comment to that effect in his reply.

[isn-removed200637]

Further to my previous post, the message displayed was the unedited version : I used the 'EDIT' option to add more and change other bits before pressing 'OK' but these changes appear to have been ignored - this appears to be the 'normal' behaviour
of the message board as I know it!

What I added was a remark that the code should display with the fixed-format code beginning in
column 7 being aligned with the 'A' in 'ATTRIBUTES'. The message board software appears to add an extra 2 spaces to lines that do not begin in column 1, at least when the

 and 

tags are used.