Thus you need to pass a pointer to MessageRes which should be declared as DWORD_PTR.
I agree that Got "LongWord" expected "QWord" isn't exactly helpful, but happily defer to the others for the correct fix.
This compiles in 32 Bit, but not in 64 Bit.You're making this too complicated for nothing. Throw out all IFDEFS altogether.
Must I declare "MessageRes" as Windows.DWORD_PTR or must I pass "MessageRes" as "@MessageRes"? Both compiles in 64 Bit.
...
However the content of "MessageRes" is not used, so if the size of the variable is correct or larger than required it should work.No "or large" ones. The size of the variable which address is passed to the function is what the function expects. In 32-bit mode, it is 32-bit, in 64-bit - 64-bit.
No...I don't understand you. You said the same thing I did, why "no"?
The Problem is: the meaning of Arg7 can change. This depends from the windows API. The answer depends from the message sent.Yes, the meaning can change, but the size of the variable, which was the question at the beginning, remains constant and equal to SizeOf (DWORD_PTR).
So the types can not tell us the full truth.
This is the prototype that Codetools point me to:The windows.pp unit include the files "ascfun.inc" and "redef.inc". The first describes the last parameter as DWORD_PTR, the second as var DWORD_PTR. Technically, this is the same, since var passes a pointer to a variable.
Is Codetools pointing to the wrong polymorphic declaration?
var lpdwResult: DWORD_PTR, this is argument 7
But "@MessageRes" is a constant pointer.
So, why can I give a constant pointer as argument for a var parameter?
There are more prototypes for this fuction and some would match.
Is Codetools pointing to the wrong polymorphic declaration? (I have seen this before with overloaded functions)
var lpdwResult: DWORD_PTR, this is argument 7
But "@MessageRes" is a constant pointer.
So, why can I give a constant pointer as argument for a var parameter?
There are more prototypes for this function and some would match.