accessing an OLE Automation (IDispatch) server from python whichrequires the use of "out params"

Discussion in 'Python' started by bitbucket, Dec 10, 2012.

  1. bitbucket

    bitbucket Guest

    I have an existing Windows application which provides an OLE Automation (IDispatch) interface. I'm not able to change that interface. I'd like to call it from a scripting language. I figure this would provide a nice quick way to invoke on the app.

    I initially tried this with Windows Powershell but ran into the following problem. I was able to create the object and invoke simple methods on it. However the interface for this app has methods which take out params. i.e.you pass in a reference to a variable and the server fills in the value. I couldn't get that to work. I finally gave up and decided it was just a limitation of Powershell, not being able to work with those out params.

    My next thought was to do it in python. I've been reading up on python andI've found a decent amount of into out there on doing OLE and I'm optimistic. But, I thought that I'd ask the question before digging too much farther into it...

    When calling an OLE Automation (IDispatch) server from python can I make use of "out params" defined by the interface?

    To get more specific, here's an example from the server's IDL for one of its methods.

    [id(15), helpstring("method GetSettingValue")] VARIANT_BOOL GetSettingValue(BSTR settingName, BSTR* settingValue);

    As you can see, you have to pass in an out param for settingValue. The server fills this in for you. And this is what I couldn't get to work in Powershell.

    Anyone know whether or not OLE from python will allow passing in out params? Do you think this will work?
    bitbucket, Dec 10, 2012
    #1
    1. Advertising

  2. bitbucket

    Terry Reedy Guest

    On 12/10/2012 2:13 PM, bitbucket wrote:
    > I have an existing Windows application which provides an OLE
    > Automation (IDispatch) interface. I'm not able to change that
    > interface. I'd like to call it from a scripting language. I figure
    > this would provide a nice quick way to invoke on the app.


    I believe the easiest way to do that is to install the pywin extensions
    http://sourceforge.net/projects/pywin32/?source=directory

    I assume it can handle out params.

    --
    Terry Jan Reedy
    Terry Reedy, Dec 10, 2012
    #2
    1. Advertising

  3. bitbucket

    bitbucket Guest

    On Monday, December 10, 2012 3:58:33 PM UTC-5, Terry Reedy wrote:
    > I believe the easiest way to do that is to install the pywin extensions
    >
    > http://sourceforge.net/projects/pywin32/?source=directory
    >
    > I assume it can handle out params.


    That definitely looks like a good starting point. Just hoping someone knows whether or not it'll support the out params before I spend too much time digging into it.
    bitbucket, Dec 10, 2012
    #3
  4. bitbucket

    bitbucket Guest

    On Monday, December 10, 2012 3:58:33 PM UTC-5, Terry Reedy wrote:
    > I believe the easiest way to do that is to install the pywin extensions
    >
    > http://sourceforge.net/projects/pywin32/?source=directory
    >
    > I assume it can handle out params.


    That definitely looks like a good starting point. Just hoping someone knows whether or not it'll support the out params before I spend too much time digging into it.
    bitbucket, Dec 10, 2012
    #4
  5. On Mon, 10 Dec 2012 13:39:00 -0800 (PST), bitbucket
    <> declaimed the following in
    gmane.comp.python.general:

    > On Monday, December 10, 2012 3:58:33 PM UTC-5, Terry Reedy wrote:
    > > I believe the easiest way to do that is to install the pywin extensions
    > >
    > > http://sourceforge.net/projects/pywin32/?source=directory
    > >
    > > I assume it can handle out params.

    >
    > That definitely looks like a good starting point. Just hoping someone knows whether or not it'll support the out params before I spend too much time digging into it.


    Well, Python itself doesn't handle "out" parameters... The win32
    extensions mostly access the defined Win32 API... May not be that useful
    for ad-hoc interfaces.

    The ctypes library may be a more direct means -- it interfaces
    between Python objects (with specific attributes/properties) used as
    data types and the C-language calling conventions... "ctypes exports the
    byref() function which is used to pass parameters by reference"

    PowerShell likely uses the same method you'd need in Python --
    passing a mutable object (an array in PS), but the receiver would need
    to be expecting such an object.
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Dec 10, 2012
    #5
  6. bitbucket

    Mark Hammond Guest

    On 11/12/2012 8:39 AM, bitbucket wrote:
    > On Monday, December 10, 2012 3:58:33 PM UTC-5, Terry Reedy wrote:
    >> I believe the easiest way to do that is to install the pywin
    >> extensions
    >>
    >> http://sourceforge.net/projects/pywin32/?source=directory
    >>
    >> I assume it can handle out params.

    >
    > That definitely looks like a good starting point. Just hoping
    > someone knows whether or not it'll support the out params before I
    > spend too much time digging into it.


    "out" params are best supported if the object supplied a typelib - then
    Python knows the params are out and does the right thing automagically.
    If out params are detected, the result of the function will be a tuple
    of (real_result, out_param1, ...)

    Even if no typelib is supported, you can access them with a little pain
    via the win32com.client.Dispatch() object. You might like to follow up
    to the mailing list where many people will be
    able to help.

    HTH,

    Mark
    Mark Hammond, Dec 11, 2012
    #6
  7. Hi,

    Am 10.12.2012 20:13, schrieb bitbucket:
    > I have an existing Windows application which provides an OLE
    > Automation (IDispatch) interface. I'm not able to change that
    > interface. I'd like to call it from a scripting language. I figure
    > this would provide a nice quick way to invoke on the app.
    >
    > I initially tried this with Windows Powershell but ran into the
    > following problem. I was able to create the object and invoke simple
    > methods on it. However the interface for this app has methods which
    > take out params. i.e. you pass in a reference to a variable and the
    > server fills in the value. I couldn't get that to work. I finally
    > gave up and decided it was just a limitation of Powershell, not being
    > able to work with those out params.


    [snipp]
    Before switching technologies I'd check if this solves your problem
    http://geekswithblogs.net/Lance/archive/2009/01/14/pass-by-reference-parameters-in-powershell.aspx


    TL;DR IMHO "out" parameters are basically pointers (pass by reference)
    and need to be passed like GetSettingValue("name", [ref]$value)...

    cheers
    Paul
    Paul Kölle, Dec 11, 2012
    #7
  8. bitbucket

    bitbucket Guest

    On Tuesday, December 11, 2012 3:42:35 AM UTC-5, Paul Kölle wrote:
    > Before switching technologies I'd check if this solves your problem
    >
    > http://geekswithblogs.net/Lance/archive/2009/01/14/pass-by-reference-parameters-in-powershell.aspx
    >
    > TL;DR IMHO "out" parameters are basically pointers (pass by reference)
    >
    > and need to be passed like GetSettingValue("name", [ref]$value)...
    >


    Thanks for the suggestion. I believe the [ref] syntax was one of the things I tried, but it didn't work in the context of OLE Automation (IDispatch) calls.
    bitbucket, Dec 11, 2012
    #8
  9. bitbucket

    bitbucket Guest

    On Tuesday, December 11, 2012 3:42:35 AM UTC-5, Paul Kölle wrote:
    > Before switching technologies I'd check if this solves your problem
    >
    > http://geekswithblogs.net/Lance/archive/2009/01/14/pass-by-reference-parameters-in-powershell.aspx
    >
    > TL;DR IMHO "out" parameters are basically pointers (pass by reference)
    >
    > and need to be passed like GetSettingValue("name", [ref]$value)...
    >


    Thanks for the suggestion. I believe the [ref] syntax was one of the things I tried, but it didn't work in the context of OLE Automation (IDispatch) calls.
    bitbucket, Dec 11, 2012
    #9
  10. bitbucket

    bitbucket Guest

    On Monday, December 10, 2012 8:16:43 PM UTC-5, Mark Hammond wrote:
    > "out" params are best supported if the object supplied a typelib - then
    > Python knows the params are out and does the right thing automagically.
    > If out params are detected, the result of the function will be a tuple
    > of (real_result, out_param1, ...)
    >
    > Even if no typelib is supported, you can access them with a little pain
    > via the win32com.client.Dispatch() object. You might like to follow up
    > to the mailing list where many people will be
    > able to help.
    >
    > HTH,
    >
    > Mark


    Mark, thanks for the reply. In this case, I have a type library and attempted to use MakePy but it doesn't seem to be working as expected.

    I was reading through CH12 of your Python Programming on Win32 book (http://oreilly.com/catalog/pythonwin32/chapter/ch12.html). I was hopeful given your description of MakePy that I could get this to work. It appears that you're saying MakePy will convert "byref" args in a function over to return values.

    For example, the IDL in the server includes the following 3 functions.

    [id(1)] void ShowMessage(BSTR msg);
    [id(2)] void GetSettingValue(BSTR settingName, BSTR* settingValue);
    [id(3)] void SetSettingValue(BSTR settingName, BSTR settingValue);

    The thorny one is the GetSettingValue since it takes the out param. When Irun MakePy, it generates the below.

    def ShowMessage(self, msg=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(1, LCID, 1, (24, 0), ((8, 0),),msg
    )

    def GetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(2, LCID, 1, (24, 0), ((8, 0), (16392, 0)),settingName
    , settingValue)

    def SetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(3, LCID, 1, (24, 0), ((8, 0), (8, 0)),settingName
    , settingValue)

    I noticed that the argument type is different for the out param (16392 instead of 8). However, it doesn't appear to me that its generating return values instead of args (though I'm not very experienced in python).

    I tried invoking these in python. The ShowMessage and SetSettingValue workgreat. I can't get the GetSettingValue to work though. Perhaps there's adifferent syntax I need when using the MakePy generated code?
    bitbucket, Dec 11, 2012
    #10
  11. bitbucket

    bitbucket Guest

    On Monday, December 10, 2012 8:16:43 PM UTC-5, Mark Hammond wrote:
    > "out" params are best supported if the object supplied a typelib - then
    > Python knows the params are out and does the right thing automagically.
    > If out params are detected, the result of the function will be a tuple
    > of (real_result, out_param1, ...)
    >
    > Even if no typelib is supported, you can access them with a little pain
    > via the win32com.client.Dispatch() object. You might like to follow up
    > to the mailing list where many people will be
    > able to help.
    >
    > HTH,
    >
    > Mark


    Mark, thanks for the reply. In this case, I have a type library and attempted to use MakePy but it doesn't seem to be working as expected.

    I was reading through CH12 of your Python Programming on Win32 book (http://oreilly.com/catalog/pythonwin32/chapter/ch12.html). I was hopeful given your description of MakePy that I could get this to work. It appears that you're saying MakePy will convert "byref" args in a function over to return values.

    For example, the IDL in the server includes the following 3 functions.

    [id(1)] void ShowMessage(BSTR msg);
    [id(2)] void GetSettingValue(BSTR settingName, BSTR* settingValue);
    [id(3)] void SetSettingValue(BSTR settingName, BSTR settingValue);

    The thorny one is the GetSettingValue since it takes the out param. When Irun MakePy, it generates the below.

    def ShowMessage(self, msg=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(1, LCID, 1, (24, 0), ((8, 0),),msg
    )

    def GetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(2, LCID, 1, (24, 0), ((8, 0), (16392, 0)),settingName
    , settingValue)

    def SetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg):
    return self._oleobj_.InvokeTypes(3, LCID, 1, (24, 0), ((8, 0), (8, 0)),settingName
    , settingValue)

    I noticed that the argument type is different for the out param (16392 instead of 8). However, it doesn't appear to me that its generating return values instead of args (though I'm not very experienced in python).

    I tried invoking these in python. The ShowMessage and SetSettingValue workgreat. I can't get the GetSettingValue to work though. Perhaps there's adifferent syntax I need when using the MakePy generated code?
    bitbucket, Dec 11, 2012
    #11
  12. bitbucket

    bitbucket Guest

    On Tuesday, December 11, 2012 10:48:53 AM UTC-5, bitbucket wrote:
    >
    > I noticed that the argument type is different for the out param (16392 instead of 8). However, it doesn't appear to me that its generating return values instead of args (though I'm not very experienced in python).
    >


    I see that the value 16392 is really VT_BYREF | VT_BSTR and 8 is just VT_BSTR. So in that case it appears MakePy is taking noticed at least of the VT_BYREF and including that in the generated code (since it uses 16392).

    So maybe there's a special way I need to call the generated wrapper?
    bitbucket, Dec 11, 2012
    #12
  13. bitbucket

    bitbucket Guest

    On Tuesday, December 11, 2012 10:48:53 AM UTC-5, bitbucket wrote:
    >
    > I noticed that the argument type is different for the out param (16392 instead of 8). However, it doesn't appear to me that its generating return values instead of args (though I'm not very experienced in python).
    >


    I see that the value 16392 is really VT_BYREF | VT_BSTR and 8 is just VT_BSTR. So in that case it appears MakePy is taking noticed at least of the VT_BYREF and including that in the generated code (since it uses 16392).

    So maybe there's a special way I need to call the generated wrapper?
    bitbucket, Dec 11, 2012
    #13
  14. bitbucket

    Mark Hammond Guest

    On 12/12/2012 2:48 AM, bitbucket wrote:
    > On Monday, December 10, 2012 8:16:43 PM UTC-5, Mark Hammond wrote:
    >> "out" params are best supported if the object supplied a typelib -
    >> then Python knows the params are out and does the right thing
    >> automagically. If out params are detected, the result of the
    >> function will be a tuple of (real_result, out_param1, ...)
    >>
    >> Even if no typelib is supported, you can access them with a little
    >> pain via the win32com.client.Dispatch() object. You might like to
    >> follow up to the mailing list where many
    >> people will be able to help.
    >>
    >> HTH,
    >>
    >> Mark

    >
    > Mark, thanks for the reply. In this case, I have a type library and
    > attempted to use MakePy but it doesn't seem to be working as
    > expected.
    >
    > I was reading through CH12 of your Python Programming on Win32 book
    > (http://oreilly.com/catalog/pythonwin32/chapter/ch12.html). I was
    > hopeful given your description of MakePy that I could get this to
    > work. It appears that you're saying MakePy will convert "byref" args
    > in a function over to return values.
    >
    > For example, the IDL in the server includes the following 3
    > functions.
    >
    > [id(1)] void ShowMessage(BSTR msg); [id(2)] void GetSettingValue(BSTR
    > settingName, BSTR* settingValue); [id(3)] void SetSettingValue(BSTR
    > settingName, BSTR settingValue);
    >
    > The thorny one is the GetSettingValue since it takes the out param.
    > When I run MakePy, it generates the below.
    >
    > def ShowMessage(self, msg=defaultNamedNotOptArg): return
    > self._oleobj_.InvokeTypes(1, LCID, 1, (24, 0), ((8, 0),),msg )
    >
    > def GetSettingValue(self, settingName=defaultNamedNotOptArg,
    > settingValue=defaultNamedNotOptArg): return
    > self._oleobj_.InvokeTypes(2, LCID, 1, (24, 0), ((8, 0), (16392,
    > 0)),settingName , settingValue)
    >
    > def SetSettingValue(self, settingName=defaultNamedNotOptArg,
    > settingValue=defaultNamedNotOptArg): return
    > self._oleobj_.InvokeTypes(3, LCID, 1, (24, 0), ((8, 0), (8,
    > 0)),settingName , settingValue)
    >
    > I noticed that the argument type is different for the out param
    > (16392 instead of 8). However, it doesn't appear to me that its
    > generating return values instead of args (though I'm not very
    > experienced in python).
    >
    > I tried invoking these in python. The ShowMessage and
    > SetSettingValue work great. I can't get the GetSettingValue to work
    > though. Perhaps there's a different syntax I need when using the
    > MakePy generated code?


    Seeing the "real" return value is void, it should just be a matter of:

    settingValue = ob.GetSettingValue("settingName")

    Mark
    >
    Mark Hammond, Dec 11, 2012
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick.O.Ige

    Ole ole

    Patrick.O.Ige, Jul 16, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    489
    Patrick.O.Ige
    Jul 16, 2006
  2. Drew Pihera
    Replies:
    0
    Views:
    640
    Drew Pihera
    Feb 4, 2004
  3. Peter Sparago

    QueryInterface on IDispatch in Python ...

    Peter Sparago, Oct 25, 2004, in forum: Python
    Replies:
    1
    Views:
    1,845
    Roger Upole
    Oct 26, 2004
  4. Brad Johnson
    Replies:
    0
    Views:
    280
    Brad Johnson
    Jul 30, 2007
  5. Replies:
    0
    Views:
    232
Loading...

Share This Page