HIMAGELIST_QueryInterface definition missing.

[440bx]

The definition of HIMAGELIST_QueryInterface seems to be missing.

C definition is at:
https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-himagelist_queryinterface

Pascal definition that must be modified to accommodate the different definition of REFIID in FPC:

Code: Pascal  [Select][+][-]

1. function HIMAGELIST_QueryInterface
2.            (
3.             { _in_  } InImageList  : HIMAGELIST;
4.             { _in_  } InIid        : REFIID;          { same as PIID / PGUID  }
5.             { _out_ } OutInterface : ppointer
6.            )
7.          : HRESULT; stdcall; external comctl32;
8.  

HTH.

[marcov]

Committed.

[440bx]

I'm guessing you made the second parameter a "const" to cause the compiler to pass an address.  Did I get that right ?

[marcov]

I'm guessing you made the second parameter a "const" to cause the compiler to pass an address.  Did I get that right ?

I think so. Copied it from other interface declarations. I'm wondering about if it shouldn't be constref though in mode objfpc. That always trips me up, as I generally use $mode delphi

[440bx]

Actually, strictly speaking, neither const nor constref are correct.

The parameter is a pointer to an IID (a REFIID which is an IID by reference) and the C definition does not _explicitly_ say that it is constant, i.e,

Code: C  [Select][+][-]

1. HRESULT HIMAGELIST_QueryInterface(
2.   [in]  HIMAGELIST himl,
3.   [in]  REFIID     riid,
4.   [out] void       **ppv
5. );
6.  

On the hand, since it is [in] and not [inout] then it is reasonable to presume it is constant (it is as far as the caller is concerned.)

In that case, specifying either "const" or "constref" will produce the same, which is passing the parameter by reference (which is what it should do) and, the call cannot change the IID from the caller's viewpoint since it is passed by value.

Succinctly, specifying either "const" or "constref" will yield the same correct result.

Choosing "const" keeps that definition consistent with already existing definitions.

One thing that would be nice would be to have an overload for the third _out_ parameter.  That way, instead of passing the address of a pointer, the call could pass the pointer itself (since out will take its address automatically.)  Obviously, that's optional since C doesn't have overloads (at least not standard C that I know of.)

[marcov]

I think the difference between const and const ref is mostly in non 32-bit x86. For the rest we adhere to the style of the other calls which is delphi inspired to avoid compatibility problems.