Click here to Skip to main content
12,297,976 members (54,574 online)
Rate this:
Please Sign up or sign in to vote.
See more: C++ Windows
Can anyone find the GUID for IOleUIObjInfo[^]?

The is no guid associated with the interface in OleDlg.h - so I can't use __uuidof(IOleUIObjInfo), and I can't find anything called IID_IOleUIObjInfo either. Still, I find it hard to believe that the interface does not have an identifying guid.

The interface is supposed to be implemented by Ole containers, and in Delphis' VCL this is the case, but Delphi (2009) defines the GUID as:
{ 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } };

Which I'm sure is not correct.

In OleDlg.h it's declared like this:
  // *** IUnknown methods *** //
  STDMETHOD(QueryInterface) (THIS_ _In_ REFIID riid, _Outptr_ LPVOID FAR* ppvObj) PURE;
  // *** extra for General Properties *** //
  STDMETHOD(GetObjectInfo) (THIS_ DWORD dwObject,
                _Out_ DWORD FAR* lpdwObjSize, 
                _Outptr_opt_result_maybenull_ LPWSTR FAR* lplpszLabel,
                _Outptr_opt_result_maybenull_ LPWSTR FAR* lplpszType, 
                _Outptr_opt_result_maybenull_ LPWSTR FAR* lplpszShortType,
                _Outptr_opt_result_maybenull_ LPWSTR FAR* lplpszLocation) PURE;
  STDMETHOD(GetConvertInfo) (THIS_ DWORD dwObject,
                _Out_ CLSID FAR* lpClassID, _Out_ WORD FAR* lpwFormat,
                _Out_ CLSID FAR* lpConvertDefaultClassID,
                _Outptr_result_maybenull_ LPCLSID FAR* lplpClsidExclude, 
                _Out_opt_ UINT FAR* lpcClsidExclude) PURE;
  STDMETHOD(ConvertObject) (THIS_ DWORD dwObject, _In_ REFCLSID clsidNew) PURE;
  // *** extra for View Properties *** //
  STDMETHOD(GetViewInfo) (THIS_ DWORD dwObject,
                _In_opt_ HGLOBAL FAR* phMetaPict, 
                _In_opt_ DWORD* pdvAspect, _In_opt_ int* pnCurrentScale) PURE;
  STDMETHOD(SetViewInfo) (THIS_ DWORD dwObject,
                HGLOBAL hMetaPict, DWORD dvAspect,
                int nCurrentScale, BOOL bRelativeToOrig) PURE;
While the documentation says it's derived from IOleUILinkContainer[^]

Ideas anybody?
Posted 14-Feb-13 12:58pm
Matthew Faithfull 14-Feb-13 20:33pm
I can confirm that Delphi has no GUID for IOleUIObjInfo as of 2012 XE3 Version 17.0.4625.53395 which is fairly up to date but doesn't have 64bit support. WINE has no definition, nor MinGW, nor ReactOS which gets its oledlg.h from WINE. The only possibilty I can think of might be if I can find my copy of the source for the old ActiveX Test Control Container which is the definitive last resort for all things ActiveX containment. I'll look but I suspect it just doesn't exist.
Espen Harlinn 15-Feb-13 3:41am
>> but I suspect it just doesn't exist.
Thanks for the input Matthew :-D

Not sure it exists outside Microsoft, but the interface seems to play an important role when you want to implement stuff related to property editing. For now I'll just give it a new Guid - which means that the interface can only be used when it's passed to functions that expect this interface, and doesn't do a QueryInterface to retrieve it from IUnknown.
H.Brydon 16-Feb-13 16:05pm
Doesn't that mean that the DLL has a COM interface but it was never registered with regsvr32 (or equiv)?

My COM skills are rusty but I think that means it is either misconfigured or it expects to be included with "#import" and class name, and not the guid.
Espen Harlinn 16-Feb-13 18:19pm
This particular interface is declared in OleDlg.h - it's part of the Windows API.
The documentation is, at least partially wrong - but the interface seems to play an important role when you want to implement property editing for ActiveX controls, but perhaps the guid is not needed - but that would mean no roundtrips trough other interfaces.

I want to implement a good container for ActiveX controls in the C++ library I'm currently working on:
and getting everthing related to COM more or less right is important if it's going to be more than a plaything ...

H.Brydon 16-Feb-13 19:34pm
Let me clarify what I meant above, about the 'misconfigured' part. My understanding of COM (which was never complete and what is there now is rusty) is that MS originally anticipated all COM objects to be registered, then later they supported unregistered COM DLLs in side-by-side mode. It became valid for a COM object to be unregistered, when #import'd by name (and then the exported APIs had to be called up by name, not guid).

I didn't mean to imply that if the COM object was unregistered that it was misconfigured (which I think could be incorrectly inferred from my comment above).

At any rate, I would think that you should be able to find a dll somewhere that exports IID_IOleUIObjInfo.

All of my comments come from C++ by the way. I see in your project that at least part of it is C#, which is outside my area of expertise.
Espen Harlinn 16-Feb-13 20:05pm
>> I see in your project that at least part of it is C#
Only a test example, there are about 13KB of c# code, and around 5MB of C++ code - so I consider it a c++ project :-D

>> MS originally anticipated all COM objects to be registered
That's probably mostly true, but over the years MS has created many interfaces that you'll only see in header files - no IDL, and no typelib - which is required for #import. By and large they've associated a GUID with the interfaces they've declared.

>> later they supported unregistered COM DLLs in side-by-side mode.
Not their brightest moment, but it probably came about by popular demand. Side-by-side should not be necessary for COM as long as you play by the rules, which includes writing proper installation programs.

>> would think that you should be able to find a dll somewhere that exports IID_IOleUIObjInfo
Doesn't seem that way, Matthew looked a lot of places - some of which I didn't think of, such as ReactOS - and neither of us has had any luck ...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.160525.2 | Last Updated 14 Feb 2013
Copyright © CodeProject, 1999-2016
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100