[pywin32-bugs] [ pywin32-Bugs-733540 ] Calling com server w/VB "Call" changes 1st param's value

[SourceForge.net <no...@so...>]

Bugs item #733540, was opened at 2003-05-07 07:57
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=733540&group_id=78018

Category: com
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ryan Groe (ryangroe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling com server w/VB "Call" changes 1st param's value

Initial Comment:
python version: 2.2.2
win32all version: 152
platform: win2k server with WSH 5.6

description:
I have a pythoncom server (using DynamicPolicy) with a 
function that takes a single parameter.  Calling that 
function from VB/VBScript using "Call" (ignoring the 
return value) causes the passed parameter to be set to 
the return value of that function.  If I assign the return 
value to a VB variable the parameter's value doesn't 
change:

'Python COM server
class Object:
  def _dynamic_(self, name, lcid, wFlags, args):
    return getattr( self, string.lower(name) )(*args)
  def func1(self, S1):
    pass

'Called From VBScript
Call obj.func1(param) 'Bad, param gets set to Null
rval = obj.func1(param) 'OK, param retains its value

I'm at a loss as to why this is.  The only difference I can 
see at the policy level is wFlags, with one style it's 3 
(DISPATCH_METHOD | DISPATCH_PROPERTYGET) 
and the other it's 1 (DISPATCH_METHOD)

Attached is a zip containing a pythoncom server, a 
VBScript test file and a batch (cmd) file to run the test.  
Please let me know if I've done something incorrectly.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-05-07 09:46

Message:
Logged In: YES 
user_id=14198

I'm afraid this is not a bug.  When you use call, VB does
not pass a value for the "result" (whereas in a normal call,
it does).  Your Python code always returns a result - when
called as a method, this is the method result - but when
called as a sub by using Call, Python passes this result
back for the first param (which VB passes as byref)

You can either examine the flags (as you noted, VB did
change the flags due to the change in semantics - in the
second case it is *not* a method) or you can create a type
library defining your interface using some external tool,
and Python will then conform (as VB will then know the
signature of the function you intended, rather than guessing
as it does now)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=733540&group_id=78018