SetWindowLongPtr is not generated

[rick-de-water]

Actual behavior

SetWindowLong is generated, but SetWindowLongPtr is not.

Expected behavior

SetWindowLongPtr should be generated to be able to set a pointer value on window.

Repro steps

1. NativeMethods.txt content:

Windows.Win32.UI.WindowsAndMessaging

2. NativeMethods.json content (if present):
   N/A

3. Any of your own code that should be shared?

unsafe private static LRESULT WindowProcedure(HWND window, uint message, WPARAM wparam, LPARAM lparam)
{
    if (message == PInvoke.WM_CREATE)
    {
        var createStruct = (CREATESTRUCTW*)lparam.Value;
        PInvoke.SetWindowLongPtr(window, WINDOW_LONG_PTR_INDEX.GWLP_USERDATA, (IntPtr)(*createStruct).lpCreateParams);
    }

    return PInvoke.DefWindowProc(window, message, wparam, lparam);
}

Context

• CsWin32 version: 0.1.635-beta
• Win32Metadata version (if explicitly set by project): N/A
• Target Framework: net6.0
• LangVersion (if explicitly set by project): 10.0

[AArnott]

Possibly related to #343

[AArnott]

This works as you expect when you target x64. AnyCPU or x86 targeted compilations don't get SetWindowLongPtr because that function only exists for 64-bit processes.
CsWin32 only generates arch-specific APIs when your compilation commits to those architectures, so this is by design.

[rick-de-water]

If it is by design then that honestly sounds like bad design. When you include windows.h you get SetWindowLongPtr, even on 32 bit processes. The documentation even recommend you to use it to be compatible with both 32 bit and 64 bit systems:

Note To write code that is compatible with both 32-bit and 64-bit versions of Windows, use SetWindowLongPtr. When compiling for 32-bit Windows, SetWindowLongPtr is defined as a call to the SetWindowLong function.

The Win32 api docs say that this function is available. This library is a wrapper around the Win32 api. The function is missing from the wrapper. This should be considered a defect, not "design".

[AArnott]

This library is a wrapper around the Win32 api. The function is missing from the wrapper.

Not exactly. This is a source generator that transforms a metadata file into C#. It doesn't read header files or try to cover any more than the metadata does in general. In some cases we go slightly beyond it just to make the existing APIs more usable, but we don't add extra APIs. CsWin32 is used with other metadata inputs than Win32Metadata, so in fact adding win32 APIs to other libraries' C# projections would be wholly inappropriate.

But I want to give you what you're asking for here. If we can get the codebase to a point where it can be flexible enough to do this, and after we get the defective code generation bugs fixed, we can circle back and look at adding conveniences like this.

It's easy for C++ to support what they do because they use macros in the header files. But in C# we can't invoke macros. We can only invoke real exported functions. And sure, we can emit totally custom code to make up for that, but users can write that code themselves too, so we need to prioritize the defect bugs.

Thanks for understanding.

[jnm2]

I'm also hearing: contributions potentially welcome.

[AArnott]

Yes, in general they are. But anything more than a trivial change should be presented in an issue with a design proposal before sending a PR to help avoid wasted effort in case it's not a PR we could accept or at least not in a particular form.
And just as fair warning for this issue, if the solution added general complexity to the overall system, we may turn it down at least for now since we don't want the added complexity to slow down our fixing of the defect issues.