Loading ...
Sorry, an error occurred while loading the content.

Trying to use XML-RPC through COM...

Expand Messages
  • Loren Amelang
    Hi, Sorry for a long story here, but I think I m in far enough over my head that it is time to ask for some help. What I originally set out to do was call the
    Message 1 of 2 , Oct 1, 2002
    View Source
    • 0 Attachment
      Hi,

      Sorry for a long story here, but I think I'm in far enough over my head
      that it is time to ask for some help. What I originally set out to do was
      call the XML-RPC capability of SOAP::Lite from my MSVC++6 app.

      First I discovered that using MSVC++ #import on Lite.dll produced two
      errors I couldn't get past:
      1 - C++ complains about the '.' in the name of "coclass SOAP.Lite",
      insisting on giving it a "member reference" meaning.
      2 - C++ complains about the "SOAP.Lite->new" method name, insisting that
      "new" is a C++ reserved word.

      Trying to shortcut around these issues, I got the PDK and made my own
      version of Lite.dll, calling the coclass "SOAPdotLite" and the method
      "SOAPnew". This imports fine and compiles, but it doesn't work, complaining
      that method "new" can't be found. (I have since put "SOAPnew" back to
      "new", so that isn't the cause of later problems with "new".)

      So I struggled through the C++ example of calling the "Hello, World"
      control using runtime access, and was able to make it work. But when I
      tried to adapt it to the XML-RPC example I was testing with, I had no luck.
      I can watch it retrieve the dispatch ID (8) of the "xmlrpc" method, but it
      doesn't work properly beyond there.

      So I tried various RPC services directly from Perl, and learned how to make
      them work. Then I tried Perl with "use Win32::OLE" on the same services,
      and was able to make them work through OLE - except for three problems:

      1 - The probably trivial problem of how to convert
      "->getTemp(SOAP::Data->name('zipcode')->type(string => $ZipCode))" into
      something that OLE can handle. I really haven't spent much time looking for
      the answer, but if someone knows, I'd like to hear about it.

      2 - What I think is the same problem I was facing in C++, of Microsoft
      products not being able to handle the '.' in "SOAP.Lite". When I "use
      Win32::OLE", only my modified version of Lite.dll works at all.

      Calling "$soap = Win32::OLE->CreateObject('SOAP.Lite')->new" with the
      original Lite.dll gets the error "Can't call method "new" on an undefined
      value - the same message as when Lite.dll isn't registered at all - (but it
      is, OLEView can see it!) If I switch the registration to my modified
      version, and the call to "SOAPdotLite", it works - for SOAP calls.

      In VBscript, calling "CreateObject("SOAP.Lite").new" gets an "unspecified
      error, line 1, char 1" _if_ the "SOAP.Lite" version of Lite.dll is
      registered. If the "SOAPdotLite" version, or no version is registered, the
      error message says it can't create the requested object. And with
      "SOAPdotLite" registered and called, SOAP requests work!

      3 - The current main problem... As long as I use my modified Lite.dll, I
      can use the "new" method or the "soap" method successfully through OLE, but
      when I try to use the "xmlrpc" method, it always dies during the
      "CreateObject" call.

      I tried using VBscript instead of PerlCOM, and found the same result.
      Calling "new" or "soap" or any other method except "xmlrpc" is successful.
      Calling "xmlrpc" gets the error "Can't locate object method "new" via
      package "XMLRPC::Lite"".

      So I'm kind of back where I was with C++, except in C++ I can see the
      "xmlrpc" method dispatch ID of 8 retrieved, so I know the ID is visible to
      COM (I can see it with OLEView, as well.) I guess the actual dll might not
      have a corresponding method for dispatch ID 8...

      I don't see where the COM dispatch IDs get numbered, not explicitly or by
      position in Lite.ctrl, or in Lite.pm. But C++ retrieves the same values
      that OLEView does. And the same lists of method names are in both places.

      I also don't understand how SOAP::Lite finds XMLRPC::Lite when the xmlrpc
      method is called through OLE. When using Perl directly, you "use
      XMLRPC::Lite" explicitly.

      And I just realized I haven't tried rebuilding Lite.dll here without
      modifying it - maybe there is some version conflict between my SOAP::Lite
      0.55 and my Lite.dll from "11/5/2001" (freshly downloaded from the web), or
      the files that came with ActivePerl 5.6.1.633... I just checked the Perl
      "VPM" and it says the current SOAP::Lite package is 0.52, not 0.55 - is
      this a problem?


      Are any of these good leads? Am I missing something painfully obvious? Or
      am I trying to do something that just isn't likely to work...

      I'm stuck with the MSVC++ app. Right now all it needs to do is XML-RPC, but
      I can already see the SOAP requirements in the future, so using a toolkit
      that can do both is very attractive. Hope I can get this to work. Any clues
      appreciated!

      Loren


      | Loren Amelang | loren@... |
    • Paul Kulchenko
      Hi Loren, ... I ll try to address your questions one by one. ... Quite possible. . is allowed in the name of COM object; I ll think about changing it to
      Message 2 of 2 , Oct 2, 2002
      View Source
      • 0 Attachment
        Hi Loren,

        --- Loren Amelang <loren@...> wrote:
        > that it is time to ask for some help. What I originally set out to
        > do was
        > call the XML-RPC capability of SOAP::Lite from my MSVC++6 app.
        I'll try to address your questions one by one.

        > First I discovered that using MSVC++ #import on Lite.dll produced
        > two
        > errors I couldn't get past:
        > 1 - C++ complains about the '.' in the name of "coclass SOAP.Lite",
        > insisting on giving it a "member reference" meaning.
        Quite possible. '.' is allowed in the name of COM object; I'll think
        about changing it to something else, but it will break the
        compatibility.

        > 2 - C++ complains about the "SOAP.Lite->new" method name, insisting
        > that "new" is a C++ reserved word.
        create()/soap() methods are provided as synonim for new() for this
        case. Both do the same. If you scan SOAP/Lite.pm for SOAP::Lite::COM
        package you'll see the details.

        > So I struggled through the C++ example of calling the "Hello,
        > World"
        > control using runtime access, and was able to make it work. But
        I'm not sure it helps in your case, but there is an example in c#
        (examples/COM/remote.cs) that uses COM interface.

        > 1 - The probably trivial problem of how to convert
        > "->getTemp(SOAP::Data->name('zipcode')->type(string => $ZipCode))"
        > into
        > something that OLE can handle. I really haven't spent much time
        > looking for
        > the answer, but if someone knows, I'd like to hear about it.

        probably something like this will work (VB):

        CreateObject("SOAP.Lite").data("name", "zipcode", _
        "type", "string", "value", ZipCode)

        > 3 - The current main problem... As long as I use my modified
        > Lite.dll, I
        > can use the "new" method or the "soap" method successfully through
        > OLE, but
        > when I try to use the "xmlrpc" method, it always dies during the
        > "CreateObject" call.
        It seems like XMLRPC::Lite module is not availble when you create
        your dll. if you use make-com-standalone.bat or make-com-minimal.bat
        file (both from examples/COM directory) to create your dll you
        shouldn't have this problem

        > I don't see where the COM dispatch IDs get numbered, not explicitly
        > or by
        > position in Lite.ctrl, or in Lite.pm. But C++ retrieves the same
        I don't know how to answer this either.

        > I also don't understand how SOAP::Lite finds XMLRPC::Lite when the
        > xmlrpc
        > method is called through OLE. When using Perl directly, you "use
        > XMLRPC::Lite" explicitly.
        It loads XMLRPC::Lite directly when you call xmlrpc() method, but it
        has to be compiled in Lite.dll already. It's included in Lite.ctrl
        script (if you use standalone version). Be sure you use ctrl files
        from v0.55

        > And I just realized I haven't tried rebuilding Lite.dll here
        > without
        > modifying it - maybe there is some version conflict between my
        > SOAP::Lite
        > 0.55 and my Lite.dll from "11/5/2001" (freshly downloaded from the
        > web), or
        That's the last available version for COM interface.

        > the files that came with ActivePerl 5.6.1.633... I just checked
        > the Perl
        > "VPM" and it says the current SOAP::Lite package is 0.52, not 0.55
        That's the version that comes with ActivePerl. If you install 0.55
        manually, information in VPM will not be updated.

        > - is this a problem?
        Shouldn't be. Just be sure you use COM directory from v 0.55

        > Are any of these good leads? Am I missing something painfully
        > obvious? Or
        > am I trying to do something that just isn't likely to work...
        No. This should work except issue with dot in "SOAP.Lite" which makes
        it difficult/impossible to use directly from MSVC++.

        > that can do both is very attractive. Hope I can get this to work.
        > Any clues appreciated!
        Hope this was helpful. If not, I'll try to dig more into it. Let me
        know if you make any progress, I'll document it or add some examples.
        Thanks.

        Best wishes, Paul.


        __________________________________________________
        Do you Yahoo!?
        New DSL Internet Access from SBC & Yahoo!
        http://sbc.yahoo.com
      Your message has been successfully submitted and would be delivered to recipients shortly.