[SOLVED] COM VT_LPSTR conversion

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

Uniface 9.6.02 We are trying to implement a COM interface to a third party dll, the import complains that there is no implementation for the data type VT_LPSTR, (Originally VT_LPWSTR) and it sets up the parameters as VT_BSTR I have checked the internet and I think this means the developer has exposed an XML element type, which boils down to a string field with $encode("URL") applied (or similar?).  I am trying to get them to change the interface, but it comes across as a bit wimpy when I say "Our com interface doesn't support this data type".  I have tried changing the signature files to VT_VARIANT, with no better effect, so the conversion complaint is based on the type in the com dll.  Does anyone have any hints (other than "write a wrapper", and "have them change they type"), this whole project is supposed to get rid of option 1 (wrapper) and I am in the process of trying option 2, I just feel bad having to go back again and again and have then change the code because Uniface doesn't support the data type they are trying to use, and there is a language barrier tripping us up on me explaining what types we DO support...  regards,  Iain

8 Comments

  1. The data types supported by the COM interface (both Call-Out and Call-In) are documented here. And a (VT_)LPSTR is a pointer to a null-terminated string, whereas (VT_)BSTR is a string data type that is used by COM, Automation, and Interop functions. The main difference between the two data types seems to be that a BSTR provides "richer" functionality. So in case you would like to interface to a third party dll from Uniface through COM then the third party should provide string parameters as (VT)_BSTR. Hope this helps. Regards, Daniel


    Author: diseli (daniel.iseli@uniface.com)
  2. In that it definitively states that my only options are to go the third party and admit I am incapable of coping with their software as is, and could they please change it for me. It does at least fix me on option 2.  Since I was trying that option anyway, and the developer has come back to me and said that he has changed the type, I still get the error on importing the signature, and I get a -150 catastrophic failure in COM on trying to use the new routine with BSTR as the parameter type. Does the /sti option use the .tlb file (as suggested by the output) or does it use the types registered using REGASM (or similar?)


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. Iain Sharp said In that it definitively states that my only options are to go the third party and admit I am incapable of coping with their software as is, and could they please change it for me. It does at least fix me on option 2. 

    I'm not sure that I've ever seen a COM object that used VT_LP(W)STR instead of VT_BSTR. And I also cannot find anything in our knowledge base concerning VT_LP(W)STR and COM Call-Out. So this does not really seem to be a commonly used data type for a COM interface. But I might be wrong.

    Iain Sharp said Since I was trying that option anyway, and the developer has come back to me and said that he has changed the type, I still get the error on importing the signature, and I get a -150 catastrophic failure in COM on trying to use the new routine with BSTR as the parameter type. Does the /sti option use the .tlb file (as suggested by the output) or does it use the types registered using REGASM (or similar?)

    It would be interesting to know what the exact error message is when importing the COM signature and also what COM error message is thrown with the -150 error (should be visible in the message frame and/or log file). And the /sti option will use the .tlb (Type Library) file if specified (e.g. /sti /mwr=com .\mytypelib.tlb). If the Program ID (/pid) is used (e.g. /sti /mwr=com /pid ProgramID) then Uniface will try to instantiate the COM object in question (using the type information stored in the registry) and query its interface (and with this info the COM signature(s) will be created). And REGASM is used to register a .Net assembly for COM and REGSVR32 for unmanaged (non .Net) COM classes. Hope this helps. Daniel


    Author: diseli (daniel.iseli@uniface.com)
  4. Okay, having re-run the /sti to try and show the error again, it no longer shows, however, when trying to use the option I get the following :-   "ICCDRV-COM-ERR Error with ICC system occurred, The COM method "InputBar1" threw an OLE exception: HRESULT=0x8000ffff, description="", source="": COM error 0x8000ffff, described as "Catastrophic failure" (ICC system status: <-2147418113>)"


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  5. Well, that's a helpful error message: "Catastrophic failure"... Confused Maybe it's time to call the emergency services... I did a quick search on the Interweb and the results are (a bit) sobering. It seems that the COM error 0x8000ffff could occur if the called COM class cannot find or load a required dependency (e.g. some required COM class is not properly registered) or if there's a problem with the type library (for details see here). It's probably a good idea to get in touch with the developer of the third party dll and ask him under which circumstances the COM class could throw the error 0x8000ffff. Sorry that I cannot be of more help (at the moment).


    Author: diseli (daniel.iseli@uniface.com)
  6. Iain Sharp said We are trying to implement a COM interface to a third party dll, the import complains that there is no implementation for the data type VT_LPSTR, (Originally VT_LPWSTR) and it sets up the parameters as VT_BSTR

    For the sake of completeness: the COM data types supported by Uniface can be found here. And the only COM data type allowed for a string is VT_BSTR (a Unicode string).


    Author: diseli (daniel.iseli@uniface.com)
  7. We have ironed out the issues with the catastrophic failure, which was him not documenting that I needed to run method A before I could run method B.... 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  8. Thanks for the update. And it's good to hear that it's working now. Smile


    Author: diseli (daniel.iseli@uniface.com)