Ok, more digging, it looks like the OLE Automation TypeLib should have a GUID Record defined. I see this when using the Python Object Browser
However, when I generate the py file for the OLE Automation type library, I don't see GUID in the RecordMap (or any reference to the GUID Record)...Is there suppose to be something in the generated file, but maybe its not working ? How do I actually create one of these Records ? On Tue, Mar 11, 2008 at 10:04 PM, Kevin Patterson <[EMAIL PROTECTED]> wrote: > I found the comtypes equivalent if that helps any. The generated comtypes > file looks like this: > > COMMETHOD([dispid(1610743812), helpstring(u'GetInterface() method')], > HRESULT, 'GetInterface', > ( ['in'], POINTER(GUID), 'riid' ), > ( ['retval', 'out'], POINTER(POINTER(IUnknown)), 'ppUnknown' > )), > > With the above, I'm able to use the comtypes.GUID.GUID structure to pass > the information over through the COM. Unfortunately I still can't find the > win32com equivalent of passing my structure through the COM. > > The win32com generated py file is saying that it expects a VT_RECORD, but > from above, maybe it should really be expecting a POINTER ? or VT_POINTER ? > I tried to modify the win32com generated file to take a VT_PTR but that > didn't seem to help. I really don't want to redo my infastructure in > comtypes, so if anyone knows the win32com equivalent, that would be awesome. > > In the meantime, I'll keep digging, and will post if I find more. > > > > On Tue, Mar 11, 2008 at 12:58 PM, Kevin Patterson <[EMAIL PROTECTED]> > wrote: > > > Old thread, but I got a little more data on the function. The function > > actually has a REFIID as the first parameter. This apparently is a standard > > structure for C COM code. I'm not entirely sure why the win32com changes > > the REFIID to be a VT_RECORD. Does the following definition of the functions > > help at all (they are from the IDL file) > > > > HRESULT GetInterface( [in] REFIID riid, [out, retval, iid_is(riid)] > > IUnknown** ppUnknown); > > should be same as: > > HRESULT GetInterface( [in] GUID* pGuid, [out, retval, iid_is(pGuid)] > > IUnknown** ppUnknown); > > > > > > > > On Mon, Feb 4, 2008 at 6:44 PM, Mark Hammond <[EMAIL PROTECTED]> > > wrote: > > > > > > guid = win32com.client.Record("GUID", some_ob) > > > > > > > I don't have the some_obj that allows me to build "GUID". > > > > > > It should be any object from the same typelib - almost certainly > > > whatever > > > object you intend passing this record to. > > > > > > > VB.NET (GetType) and C++ (__uuid) both already know that a GUID is a > > > record. > > > > > > C++ doesn't know it is a COM record. A COM record is something quite > > > different to a C/C++ struct or from .NET types. A COM record is > > > specifically designed to be cross-language. > > > > > > > It seems the python CLSID is the same thing, but i don't know what > > > to call > > > > > > > to get a CLSID that is a com_record type. > > > > > > As I've explained, we are looking for the COM record definition you > > > are > > > trying to use. A C++ struct definition for a GUID is *not* what you > > > are > > > looking for - you are looking for the COM record definition of a GUID. > > > I > > > see now that you simply copied me a C++ struct you found, which is not > > > at > > > all useful in this context. > > > > > > To clarify: in a *typelib* you will find a struct definition that you > > > are > > > trying to use. Finding a struct definition of the same name somewhere > > > else > > > is not suitable. > > > > > > > Am I understanding the win32com.client.Record call correctly? It > > > needs > > > GUID to be defined by the > > > > COM right? > > > > > > Not "defined by COM", but "defined using COM" - the author of a > > > typelib must > > > have defined it somewhere. > > > > > > > Its odd b/c the GIUD (python's CLSID) is all over the COM > > > definitions its > > > just type > > > > VT_RECORD type that I'm not understanding how to convert to. > > > > > > Yes, I'm afraid you are confused. All existing GUID or CLSID > > > definitions > > > you can find are useless - there is only 1 that is relevant, and that > > > will > > > be defined in a typelib. > > > > > > I think the confusion is such that you need to find basic docs for the > > > object, so we can get back to square 1. > > > > > > Mark > > > > > > > > >
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32