#1658 closed Bug (Fixed)
COM / OLE object access causes error code 80020003 - member not found
Reported by: | Frank <temp.kfl42ai@…> | Owned by: | Jon |
---|---|---|---|
Milestone: | 3.3.7.22 | Component: | AutoIt |
Version: | Other | Severity: | None |
Keywords: | COM / OLE Object - Error Code 80020003, Member not found | Cc: |
Description
Hallo,
while writing some AutoIt scripts to automate one of our ERP-Applications, which includes an OLE / COM Interface with late bindung, I get some exceptional errors.
For some methods of the COM-Objects, the following error was reported: COM-Object error 80020003, Member not Found.
The same methods or rather the whole COM Interface works fine when using it with other programming languages like VBA, VBScript, C# VC++ etc. in the same environment (OS etc.) and the same manner (syntax etc.).
Therefor the software vendor says that his application (written in Delphi) and its COM-Interface (Type: late bindung) is in proper style and it must be an problem with AutoIt.
Here is an example:
Local $oHWP Local $wert Local $i $oHWP = ObjCreate ("HWP.Anwendung") if ($oHWP.Angemeldet = 0) Then ; check if logged in -> works $oHWP.Anmelden ("USER","PASSWORD") ; login with credentials -> ; cause COM-Error 80020003 - ; Member not found endif $wert = $oHWP.Version ; get version number -> works $wert = $oHWP.Table("ADR").Anzahl ; number of contacts -> works $oHWP.Table("ADR").ErsterSatz ; go to first record -> ; cause COM-Error 80020003 - ; Member not found" For $i = 1 to $wert ; do something with current record, $oHWP.Table("ADR").NaechsterSatz ; go to next record -> works Next $oHWP = 0 Exit
It's very strange that the statement "$oHWP.Table("ADR").NaechsterSatz" works fine while the statement "$oHWP.Table("ADR").ErsterSatz" causes an error although both works fine while using them in many other programming languages.
Also an simple call of the method "$oHWP.Anmelden ("...")" causes an error 80020003 while it doesn't in VBA etc.
Is there a bug in AutoIt?
P.S.:
- All error codes are determined by standard error handling of AutoIt ($oMyError = ObjEvent("AutoIt.Error","MyErrFunc") etc.), which was omit for the reason of clarity of code.
- Using of COM methods (syntax etc.) in the example above is in accordance of the programming guidelines of the software vendor
With best regards, Frank
Attachments (0)
Change History (17)
comment:1 follow-up: ↓ 2 Changed 14 years ago by Jpm
comment:2 in reply to: ↑ 1 Changed 14 years ago by Frank <temp.kfl42ai@…>
Replying to Jpm:
Frank,
It will be more than difficult to analyze what's wrong in AutoIt without the file(s) allowing to create the object "HWP.Anwendung" and execute it.
Hallo,
after some additional tests i found out, that only methods which are implemented as "procedures" (without a return value) are affected
Methods which are implemented as "functions" (with a return value) and properties works fine.
Possibly, AutoIt has a problem with those kind of methods (without a return value), since the COM-Interface works well with all other tested languages (VBA, VBS, VC, C#, Delphi).
Is there a workaround, e.g. a stub procedure which is calling object methods with a DllCall where the object variable is passed per DllStruct or something else?
P.S.: i can provide a fully functional demo version of that ERP Application on my FTP-server for you to download
comment:3 follow-up: ↓ 4 Changed 14 years ago by Jpm
- Owner set to Jon
- Status changed from new to assigned
Thanks,
In fact I hope Jon or Valik can enter this testing as I don't know enough about COM AutoIt implementation. They certainly request you more but perhaps your last post will help them without the FTP. ;)
comment:4 in reply to: ↑ 3 Changed 14 years ago by Frank <temp.kfl42ai@…>
Replying to Jpm:
Thanks,
In fact I hope Jon or Valik can enter this testing as I don't know enough about COM AutoIt implementation. They certainly request you more but perhaps your last post will help them without the FTP. ;)
Thanks to DaX an ProgAndy from the german AutoIt Community, I've got the following workaround and it works fine.
It based on MS ScriptControl, so all problematic methods can be executed as "embedded" VBS code.
#Region *** Declares *** Global $oHWP Global $oScriptHost Global $sCode Global $retVal #EndRegion *** Declares *** #Region *** Init ScriptControl *** $oScriptHost = ObjCreate("ScriptControl") $oScriptHost.Language = 'vbscript' $oScriptHost.Modules.Add('HWP') $sCode = 'Sub Anmelden(ByVal HWP, ByVal Benutzer, ByVal Kennwort)' $sCode &= @CRLF & 'HWP.Anmelden Benutzer, Kennwort' $sCode &= @CRLF & 'End Sub' $sCode &= @CRLF & 'Sub ErsterSatz(ByVal HWP)' $sCode &= @CRLF & 'HWP.Table("ADR").ErsterSatz' $sCode &= @CRLF & 'End Sub' $sCode &= @CRLF & 'Sub NaechsterSatz(ByVal HWP)' $sCode &= @CRLF & 'HWP.Table("ADR").NaechsterSatz' $sCode &= @CRLF & 'End Sub' $oScriptHost.Modules('HWP' ).AddCode($sCode) #EndRegion *** Init ScriptControl *** $oHWP = ObjCreate('HWP.Anwendung') If ($oHWP.Angemeldet = 0) Then $oScriptHost.Modules('HWP' ).Run('Anmelden', $oHWP, 'USERNAME', 'PASSWORD') EndIf $retVal = $oHWP.Version $retVal = $oHWP.Table('ADR' ).Anzahl $oScriptHost.Modules('HWP' ).Run('ErsterSatz', $oHWP) For $i = 1 To $retVal MsgBox(0, 'Information', $oHWP.Table('ADR' ).Feld('Nummer')) $oScriptHost.Modules('HWP' ).Run('NaechsterSatz', $oHWP) Next $oHWP = 0 $oScriptHost = 0
On the other hand, this workaround shows, that AutoIt might have a problem with calling methods of a "late binding" COM-Interface that don't return a value, cause calling those methods work fine in VBS.
@Jon, @Valik: for further information feel free to contact me
comment:6 Changed 13 years ago by Jon
- Milestone set to 3.3.7.9
- Resolution set to Fixed
- Status changed from assigned to closed
Fixed by revision [6121] in version: 3.3.7.9
comment:7 Changed 13 years ago by Valik
- Resolution Fixed deleted
- Status changed from closed to reopened
Apparently this may not be fixed so I'm reopening it until I can test one way or the other.
comment:8 Changed 13 years ago by MeJonah@…
Yep, I didn't read the ticket guidelines and posted another ticket on it when I shouldn't have. Sorry about that. Here's the text from the other ticket, which includes a re-create for a scenario I know isn't working in 3.3.7.18.
The code below properly opens the report in 3.3.6.0, but causes a COM "member not found error" on the line $CR_ObjViewer.ReportSource = $CR_ObjReport (commented in the code).
#Region ; Directives created by AutoIt3Wrapper_GUI
#AutoIt3Wrapper_UseX64=n
#EndRegion ; Directives created by AutoIt3Wrapper_GUI
$oMyError = ObjEvent("AutoIt.Error","MyErrFunc") ; Initialize a COM error handler
Func MyErrFunc()
Msgbox(0,"AutoItCOM Test","We intercepted a COM Error !" & @CRLF & @CRLF & _
"err.description is: " & @TAB & $oMyError.description & @CRLF & _
"err.windescription:" & @TAB & $oMyError.windescription & @CRLF & _
"err.number is: " & @TAB & hex($oMyError.number,8) & @CRLF & _
"err.lastdllerror is: " & @TAB & $oMyError.lastdllerror & @CRLF & _
"err.scriptline is: " & @TAB & $oMyError.scriptline & @CRLF & _
"err.source is: " & @TAB & $oMyError.source & @CRLF & _
"err.helpfile is: " & @TAB & $oMyError.helpfile & @CRLF & _
"err.helpcontext is: " & @TAB & $oMyError.helpcontext _
)
Local $err = $oMyError.number
If $err = 0 Then $err = -1
$g_eventerror = $err ; to check for after this function returns
Endfunc
$gui = guicreate("TEST", 500, 500)
$sReportName = FileOpenDialog("Select RPT Source File", ".", "RPT (*.rpt)", 3)
if $sReportName <> "" and fileexists($sReportName) then
$CR_ObjApp = ObjCreate("CrystalRuntime.Application.11")
If $CR_ObjApp = 0 Then
msgbox(0, "Error", "Crystal Reports is not installed.", default, $gui)
else
$CR_ObjReport = $CR_ObjApp.OpenReport($sReportName)
If $CR_ObjReport = 0 Then
msgbox(0, "Error", "Unable to open report.", default, $gui)
else
$CR_ObjViewer = ObjCreate("CrystalReports11.ActiveXReportViewer.1")
$CR_ObjViewer.DisplayGroupTree = true
;Creates an ActiveX control in the GUI.
$ActiveX = GUICtrlCreateObj ( $CR_ObjViewer, 10, 10, 480, 480)
$CR_ObjViewer.ReportSource = $CR_ObjReport ;this line causes a COM error "member not found" in beta 3.3.7.10, but not in earlier non-beta versions
$CR_ObjViewer.ViewReport
endif
endif
endif
Of course CR must be installed, here is a thread discussion on it: http://www.autoitscript.com/forum/topic/12813-crystal-reports-viewer-in-autoit/
comment:9 Changed 13 years ago by anonymous
The other, duplicate ticket is here: http://www.autoitscript.com/trac/autoit/ticket/1963
comment:10 Changed 13 years ago by TicketCleanup
- Milestone 3.3.7.9 deleted
Automatic ticket cleanup.
comment:11 Changed 13 years ago by Jpm
ActiveX download links are no more available. Please update if you want some testing be done
Thanks
comment:12 Changed 13 years ago by MeJonah@…
I am attempting to come up with something, and will post it soon.
comment:13 Changed 13 years ago by trancexx
This should be fixed with the next beta (3.3.7.22). Please test if you know how.
I will close this ticket soon as fixed unless somebody proves it still exists.
comment:14 Changed 13 years ago by MeJonah@…
Yep, it is fixed. You guys are awesome, especially considering I was never able to get you the CR runtime to test with.
comment:15 Changed 13 years ago by trancexx
- Resolution set to Fixed
- Status changed from reopened to closed
- Version 3.3.6.0 deleted
Great, closing then.
Fixed by revision [6475] in version: 3.3.7.22
comment:16 Changed 13 years ago by TicketCleanup
- Milestone set to Future Release
- Version set to Other
Automatic ticket cleanup.
comment:17 Changed 13 years ago by Jpm
- Milestone changed from Future Release to 3.3.7.22
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
Frank,
It will be more than difficult to analyze what's wrong in AutoIt without the file(s) allowing to create the object "HWP.Anwendung" and execute it.