DefWindowProc Attributes Declaration

[garyscott]

Hi,

In order to resolve a linking error for defwindowproc, I have to change the attributes declaration from:

!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'DefWindowProcA' :: DefWindowProc

to:

!DEC$ ATTRIBUTES DEFAULT, STDCALL, ALIAS:'_DefWindowProcA@16' :: DefWindowProc

version.lib kernal32.lib and user32.lib are specified on the link command

What is the difference in the above?

[Steven_L_Intel1]

Shouldn't be any difference if the interface defines four arguments, which it seems to. What symbol is the linker looking for if you don't make the change? What compile options are specified?

[Jugoslav_Dujic]

There's supposed to be no difference (except that DEFAULT is supported since CVF 6.5), however...

I filled in a bug report (found outin a subclassing example, "Menu Dialog") where CVF cannot work out a reference on calling side if you don't ever actually directly call the routine, but reference it by other means, for example:

subroutine Foo

use dfwin

iMsg = CallWindowProc(LOC(DefWindowProc), hWnd, Msg, wParam, lParam)

end subroutine Foo

Steve explained to me that it's difficult to get right (I agree) and that it won't get fixed. A workaround is to... find a workaround. For example, adding a

if (.false.) then

iMsg = DefWindowProc(hWnd, Msg, wParam, lParam)

end if

"explains" to the compiler what DefWindowProc really is, automagically fixing the first error (if the optimizer doesn't remove unreachable code :smileywink:).

Is that your situation? Note that you may call DefWindowProc directly, not via CallWindowProc (semantic differences are subtle and you can usually ignore them).

Jugoslav

[garyscott]

Link is looking for "_defWindowProcA"

i.e. no decoration assumed by link. Argument passing convention options are:

DEFAULT, UPPER CASE, STRING LENGTH ARGUMENT INLINE

It is true that I'm not making a direct call to this routine anywhere. I'm simply assigning it to thelpfnWndProc component of the window class structure destined for registerclass: = loc(defwindowproc) !MsgLoop

Linking works also if I map an undefined alias name for it (i.e. myMSGLoop, without defining such a function in my code).

link options:

c:gino60gmenuwdg.lib c:gino60ginlibdg.lib c:gino60gmwinerr.lib version.lib kernel32.lib user32.lib u:f95sourceezconsole eleaseezconsole.lib /nologo /entry:"mainCRTStartup" /subsystem:windows /incremental:no /pdb:"Release/TestGino50.pdb" /machine:I386 /out:"Release/TestGino50.exe"

Note: entryused by GINO app.

EXE compile options:

/compile_only /debug:none /include:"Release/ u:f95sourceezconsole elease" /nologo /warn:nofileopt /winapp /module:"Release/" /object:"Release/"

Static library compile options:

/compile_only /nologo /warn:nofileopt /module:"Release/" /object:"Release/"

[garyscott]

I am not calling it directly, I am assigning it to a structure componentfor use in the registerclass API (see my other post). Is thatthe same situation you describe?

[Steven_L_Intel1]

Ah, yes, now I remember. The DECORATE attribute doesn't work if you're not actually calling the routine. I think that for this routine, at least, it might make sense for us to not use DECORATE and spell out the name in full.

[Jugoslav_Dujic]

...while you're at it, DefDlgProcand DefMDIChildProc fall in the same category.

Jugoslav

[Jugoslav_Dujic]

...to Garry: you can workaround it if you manage to call DefWindowProc from the same procedure (WinMain?). I think that inserting:

iRet = DefWindowProc(GetDesktopWindow(), WM_NULL, 0, 0)

anywhere (even as a last line)causes no harm, and resolves the problem.

Jugoslav

[garyscott]

Thanks. I have resoved it by creating a "properly structured" message loop of my own with explicit fall-through call to defwindowproc within. My prior setup was intended to be temporary while I tested other code (tweaking the window settings themselves before moving on to the message loop).