GetDC incorrectly returns, and DrawIconEx incorrectly requires, a safe handle that calls DeleteDC instead of ReleaseDC

[jnm2]

Related, possible solution: microsoft/CsWin32#111

GetDC is paired with ReleaseDC, not DeleteDC.

DrawIconEx and probably all other APIs taking hdc parameters do not care what kind of DC you pass it, so DeleteDC/ReleaseDC should not be encoded into the names of the types used by any of their parameters.

[AArnott]

The SafeHandle parameter types you call out is fixed by microsoft/CsWin32#9.

The GetDC pairing is an issue with the metadata, so I'm transferring the issue there.

[sotteson1]

Ugh, CreateDC needs DeleteDC, and GetDC needs ReleaseDC. Any suggestions on how to represent that?

[AArnott]

I vaguely recall a proposal I made for expressing a hierarchy of handles in the metadata, such that projections could try to make them look polymorphic while still treating them differently. It might have been in the GDI context.
But as there are just two types here and no obvious "parent", yet all the consumers may accept either one, it seems we should create a name for a 'base' handle and use it for all inputs in the metadata. Then for the two "derived" handles, which are never used except as return types, we attribute these derived handle types with their base handle name so projections can make sure a derived handle can be used where the base handle appears as input.

[sotteson1]

Yeah, that makes sense. You could also use one as the base type and have the other be derived from it. It would be like overriding the destructor with the correct close function.

[RAIIFree("ReleaseDC")]
[NativeTypedef]
public struct HDC
{
    public IntPtr Value;
}

[RAIIFree("DeleteDC")]
[DerviesFrom("HDC")]
[NativeTypedef]
public struct HDC2
{
    public IntPtr Value;
}

HDC hdc = GetDC()
HDC2 hdc2 = CreateDC()

BitBlt(hdc, ...)
BitBlt(hdc2, ...)

So HDC2 "is a" HDC and can be used in the same places as HDC.

[AArnott]

Right. Technically structs can't derive from other structs in C# (or ECMA AFAIK), but let the projections worry about that.

[sotteson1]

It could also be implemented as an operator from one to another. Maybe the attribute could be called "ConvertsTo"?

[kennykerr]

Rust also doesn't support inheritance of any kind so an attribute would be preferable.

[AArnott]

Maybe the attribute could be called "ConvertsTo"

That invites the question : "ok, how?"

No conversion is necessary. So how about AlsoUsableForAttribute?

[sotteson1]

I'm fine with that name.