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.

[Lamparter]

The docs say that SetWindowLongPtr should be generated as an alias to SetWindowLong on x86 configuration.

However, CsWin32 does not generate the SetWindowLongPtr method in the above described way.
It should be configured to do this as the documentation recommends for Win32 apps.

[AArnott]

The documentation doesn't dictate what CsWin32 does, but rather what you would expect from header files. And in general, macros in header files are not functions and are therefore not emitted by CsWin32.
That said, I see 3 up-votes on this, so I'll reactivate.

[Lamparter]

The documentation doesn't dictate what CsWin32 does, but rather what you would expect from header files

Of course, but I find it ironic that the XMLDoc comment says "on x86 this function is an alias to SetWindowLong" when it is in fact not, and a build error is displayed when using Setwindowlongptr on x86 as it is not generated in that way by the core CsWin32 generator.

[AArnott]

Ya... that is ironic and unfortunate. We just scrape the documentation, which was only written with C in mind. :(