Open Zerowalker opened 2 years ago
This constant appears to be available as Windows.Win32.UI.Shell.FileOpenDialog
.
Oh indeed, that's confusing, have I missed something?
The win32 metadata uses the CLSID_
prefix for some constants but not for others. I'm not sure why.
Ah okay, hmm. Makes it difficult to know if it exists or not. How did you look it up?
If you can't find CLSID_Widget
then just try searching for Widget
instead.
got it thanks
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
Oh, so you mean the naming convention of CLSID_ is or is not intended to be kept?
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.
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.
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);
@tannergooding is there anything we can do with ClangSharp to better scan CLSID constants like below?
https://github.com/microsoft/win32metadata/issues/994#issuecomment-1204697492 https://github.com/microsoft/win32metadata/issues/271#issuecomment-783119742
Alternatively, we could try to detect this pattern in our ConstantsScraper that walks the headers line by line.
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.
I could probably add some special casing to recognize
CLSID_*
andIID_*
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.
Noticed that
CLSID_FileOpenDialog
is missing which is located inShObjIdl_core.h
. Looked at some others in there as well which was also missing, so it might be the whole thing?