CLSID from ShObjIdl_core.h is missing

[Zerowalker]

Noticed that CLSID_FileOpenDialog is missing which is located in ShObjIdl_core.h.
Looked at some others in there as well which was also missing, so it might be the whole thing?

[kennykerr]

This constant appears to be available as Windows.Win32.UI.Shell.FileOpenDialog.

[Zerowalker]

Oh indeed, that's confusing, have I missed something?

[kennykerr]

The win32 metadata uses the CLSID_ prefix for some constants but not for others. I'm not sure why.

[Zerowalker]

Ah okay, hmm. Makes it difficult to know if it exists or not.
How did you look it up?

[kennykerr]

If you can't find CLSID_Widget then just try searching for Widget instead.

[Zerowalker]

got it thanks

[mikebattista]

There might be some bugs with how we process CLSIDs defined like:

EXTERN_C const CLSID CLSID_FileOpenDialog;

#ifdef __cplusplus

class DECLSPEC_UUID("DC1C5A9C-E88A-4dde-A5A1-60F82A20AEF7")
FileOpenDialog;
#endif

[Zerowalker]

Oh, so you mean the naming convention of CLSID_ is or is not intended to be kept?

[mikebattista]

If CLSID_* is how you're meant to reference these, then we should be including that format in the metadata, but not all CLSIDs are defined the same way, so we might need special handling in cases like this.

[Zerowalker]

Oh, could you enlighten me with an example of a CLSID that's defined differently?
Was under the impression they all had that.
Except if there isn't any and you call __uuidof on the type.
But that might be something else entirely.

[mikebattista]

Look at shlguid.h for example.

DEFINE_GUID(CLSID_AutoComplete,         0x00BB2763L, 0x6A77, 0x11D0, 0xA5, 0x35, 0x00, 0xC0, 0x4F, 0xD7, 0xD0, 0x62);
DEFINE_GUID(CLSID_ACLHistory,           0x00BB2764L, 0x6A77, 0x11D0, 0xA5, 0x35, 0x00, 0xC0, 0x4F, 0xD7, 0xD0, 0x62);
DEFINE_GUID(CLSID_ACListISF,            0x03C036F1L, 0xA186, 0x11D0, 0x82, 0x4A, 0x00, 0xAA, 0x00, 0x5B, 0x43, 0x83);

[mikebattista]

@tannergooding is there anything we can do with ClangSharp to better scan CLSID constants like below?

#994 (comment)
#271 (comment)

Alternatively, we could try to detect this pattern in our ConstantsScraper that walks the headers line by line.

[tannergooding]

ClangSharp has a --with-guid which lets you explicitly specify a GUID that should be attached to a given type.

Having a Guid makes a type considered no longer "empty", even if it has no fields/members and correspondingly causes the relevant [Guid("...")] attribute to be emitted on the type.

I would expect this to be automatically picked up for something like FileOpenDialog. That is, I'd expect you're already getting something similar to this generated:

[Guid("DC1C5A9C-E88A-4DDE-A5A1-60F82A20AEF7")]
public partial struct FileOpenDialog
{
}

For CLSID_FileOpenDialog the general issue is that the top level declaration has no resolvable initializer, so we can't define anything. The initializer is why IID_IDXGIFactory and many other DirectX IID or other CLSID declarations work.

I could probably add some special casing to recognize CLSID_* and IID_* for a type * that was resolved to have a [Guid("...")] member. If you could log a feature request for that, I can work on getting that done.

-- Clang 16 is supposed to ship in the next month and I plan on getting the bulk of the feature requests completed and a new version of ClangSharp out around that time.

[mikebattista]

I could probably add some special casing to recognize CLSID_* and IID_* for a type * that was resolved to have a [Guid("...")] member. If you could log a feature request for that, I can work on getting that done.

This would be awesome! I'll file an issue.

Yes we do already scrape FileOpenDialog as you showed. The problem is CLSID_FileOpenDialog is what is documented and what everyone is expecting and they're having a hard time finding the unprefixed version. We've had several issues filed on this and there's also just general inconsistency in the metadata since many GUIDs that are defined differently in the headers are scraped as CLSID_, while the ones that follow this pattern are not.