#71 "Scriptlet.Typelib": OLE error 92.901 occurred (80070057)

v3.0
closed
None
5
2012-08-14
2005-05-15
No

Supposedly scripts can easily have GUID values created
by repeatedly accessing the "GUID" property of an
instance of the COM class "Scriptlet.Typelib".

A Visual Basic Script file that works looks like this
(save and double-click on the file or enter the full
file-name on the command line):

--------------- cut here --------------
' VBS-version, executed via "cscript.exe" or "wscript.exe"
Dim guid
guid = CreateObject("scriptlet.typelib").guid
WScript.Echo guid
--------------- cut here --------------

Here the equivalent ooRexx version:
--------------- cut here --------------
-- RXS-version, executed via "cscript.exe" or "wscript.exe"
guid=.OleObject~new("scriptlet.typelib")~guid
WScript~Echo(guid)
--------------- cut here --------------

Neither the ooRexx equivalent nor a "pure" Rexx
equivalent (see below) work, they both come up with an
OLE runtime error 92.901 ("An unknown OLE error occured
(HRESULT=80070057).")

Error "80070057" is sometimes described as "Invalid
Parameter" on the net. "GUID" is defined to be a
read/writable property of type VT_BSTR.

Here an ooRexx-example to demonstrate the problem
(bombing on the second line, i.e. the say-statement in
which the property "GUID" gets accessed):

--------------- cut here --------------
o=.oleObject~new("scriptlet.typelib")
say o~guid
--------------- cut here --------------

Discussion

  • Rony G. Flatscher

    Logged In: YES
    user_id=662126

    Sorry, forgot to denote the filenames:

    VB-Script, e.g. "GUID.VBS"
    ooRexx-Script, e.g. "GUID.RXS"
    ooRexx, e.g. "GUID.rex"

    "VBS" and "RXS" filetypes are associated with "wscript.exe"
    (Windows, i.e. GUI version for echo-outputs which cause
    popups to appear) and can be executed also with:
    "cscript.exe" (command line version, output on commandline,
    no halting of the script to confirm the output)

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-09-20

    Logged In: YES
    user_id=191588

    I submitted patch # 1562476 that fixes this bug.

    This bug was caused by an incorrect look up of the
    function (method) information for a call to Invoke() in
    the fFindFunction() function in orexxole.c

    Within fFindFunction(), when a function (method) name was
    matched there was a convoluted check to see if: (the
    passed flags indicated a property put and the function
    invocation kind was a property put) OR the passed flags
    did not indicate a property put.

    If that check passed, another check was made to see if the
    function's parameter count was greater than or equal to
    the expected parameter count.

    Property puts and gets in OLE usually have the same
    function name.

    When the function being sought was a property get and the
    first function with the same name encountered was a
    property put this is what happened:

    The first check passed (flags did NOT indicate a property
    put.) Property gets usually have 0 parameters and
    property puts at least 1, so the second check also passed
    (parameter count of 1 is greater than or equal to 0.)

    This then caused Invoke() to be called with the
    information for a property put, when it was suppossed to
    be a property get, and the Invoke()call failed.

    The only reason this bug did not show up far more often,
    is that most type libraries seem to have the property get
    method before the property put.

    The patch fixes the look up so the correct function
    information is returned.

     
  • Rick McGuire

    Rick McGuire - 2006-09-20

    Logged In: YES
    user_id=1125291

    Fixed by [ 1562476 ] Patch fro Bug # 1202335

    Contributed by Mark Miesfeld. Thanks Mark!

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks