Click here to Skip to main content
Rate this: bad
good
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:
DECLARE_INTERFACE_(IOleUIObjInfoW, IUnknown)
{
  // *** IUnknown methods *** //
  STDMETHOD(QueryInterface) (THIS_ _In_ REFIID riid, _Outptr_ LPVOID FAR* ppvObj) PURE;
  STDMETHOD_(ULONG,AddRef) (THIS) PURE;
  STDMETHOD_(ULONG,Release) (THIS) 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
Comments
Matthew Faithfull at 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 at 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 at 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 at 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: http://www.codeproject.com/Articles/471662/Windows-Development-in-Cplusplus-working-with-menu and getting everthing related to COM more or less right is important if it's going to be more than a plaything ...
H.Brydon at 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 at 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
Your Filters
Interested
Ignored
     
0 Sergey Alexandrovich Kryukov 397
1 OriginalGriff 350
2 thatraja 205
3 Emre Ataseven 165
4 Shai Vashdi 150
0 Sergey Alexandrovich Kryukov 8,894
1 OriginalGriff 5,200
2 Peter Leow 3,955
3 Maciej Los 3,535
4 Abhinav S 3,208


Advertise | Privacy | Mobile
Web04 | 2.8.140415.2 | Last Updated 14 Feb 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Use
Layout: fixed | fluid