> That's odd. Is your application compiled with -DUNICODE? BSTR is > always Unicode, but LPCTSTR depends on the compiled character set. I > would expect it to be LPCWSTR. However, if it works for > "obj_2.SubObject.DoSomething", then that's not a problem.
It's compiled with /D "_MBCS" so it should indeed be a wide string. But I don't think it's related to the character set as it also fails e.g. with integer arguments. Consider the following snippet: # subobject nnames = obj_1.SubObj.GetNumberOfNames # nnames: 4 -> ok! names = [obj_1.SubObj.GetName(i) for i in xrange(nnames)] # names: [u'a', u'PP', u'N', u'L'] -> ok! # parent object nnames_2 = obj_1.GetNumberOfNames # nnames_2: 4 -> ok! names_2 = [obj_1.GetName(i) for i in xrange(nnames_2)] # pnames: [None, None, None, None] -> wrong! So again it works on the sub object but not on the parent (if anything, I'd have expected it the other way around if maybe the subobject could not be determined properly). The methods share the same interface and implementation in both objects, they even use the same C++ command base class. They should return the same results not only for number of names but also the names. DISP_FUNCTION(CMyCommand, "GetName", GetName, VT_BSTR, VTS_I4) BSTR CMyCommand::GetName(long index) But even completely without strings, simple methods won't work on obj_1, e.g. something like double CosD(double degrees), but will work on SubObj, e.g. double GetValue(long index). Long story short, it seems the only thing I can get to work on obj_1 are methods without any arguments. On SubObj, most things seem to work except for call-by-ref parameters. > What do you mean by "doesn't work"? Is the method missing, or do you > get trash results? I don't get a Python exception (or any result or output). I can also see that in the C++ code the method is not called. I even tried to set earlier breakpoints in OLE message handlers but wasn't able to find any trace of evidence that some COM call was triggered at all. > By "implemented correctly", I really meant "declared correctly". The > IDispatch handler in your code doesn't have a clue what the C++ function > signatures actually are. It has to trust your dispatch map. If there > is disagreement, garbage results. Ok, I get that. However since the same interface is working without problems with VBA I'm doubtful if it is really related to a wrong interface declaration. Is there any way to explicitly tell the Python wrapper about the interface to use without using makepy? _______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
