Smith, Brian (CR) wrote: >> > > I am new to COM programming and have a question about function > > parameters when implementing a COM object in Python. > > > > After reading "Python Programming on Win32", I have managed to create a > > working COM object, where "working" is defined as "I can use it from > > Excel VBA". > > > > I have a function like this: > > > > def func(self, in1, inout1, in2, inout2) > > ... > > but it breaks if the VB program does this: > > > > c1 = CONSTANT_1 ' c1 is a previously declared variable > > c2 = 7.4 ' c2 is a previously declared variable > > errorCode = object.func( c1, var1, c2, var2 ) > > > > because c1 will then be assigned new_inout1 and var1 will be assigned > > new_inout2, while c2 and var2 will not be assigned anything. > > > > Short of telling the VB programmer "Don't do that", how do I prevent > > this problem?
Tell the VBA programmer "Don't do that". Or, rearrange the parameters so that the inout arguments are always first. This very same question came up on this list in June, and I actually spent quite a bit of time trying to chase down documentation of this restriction. Surprisingly enough, the "fault" here is not actually in Python: it's in the late binding handler in VBA. If you do this same thing from a VB app and look at the generated IL code, it is the IL that is assigning the outputs to the wrong place. -- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
