SvenP

I seems that no one answered this one since October 6. Well, I can make it short: Inside a GUI you can only embed ActiveX controls or hybrid COM Objects that have additional ActiveX functions. The 'Shell.Application' object does not have ActiveX functions. You can check if an object could be used inside a GUI by using the 'Oleview' utility. The object should at least have the IOleControl and IOleInPlaceObject interfaces listed. But that's even no guarantee that it will work inside a GUI. Regards, -Sven

I have written some IP helper functions several months ago. They include: GetAdapterInfo() SendArp() IsReachable() AddStaticRoute() DeleteStaticRoute() GetIfEntry() inet_addr() GetPublicIP() GetLocationInfo() The file is attached below. iphelper.au3 NOTE: It is unsupported, not fully tested and barely documented. Use at your own risk. Maybe I will write a full UDF from this, only if I had some more spare time left.. Regards, -Sven

He's a test script I wrote about a year ago, testing the ActiveX GUI functions: Before you run it, change line 14 with a filename of an existing excel sheet. #include <GUIConstants.au3> ; ; Embedding an Excel document inside an AutoIt GUI ; ; Limitations: ; ; 1. Integrating the GUI Menu with the Objects Menu does not work. ; (they have seperate menu bars) ; ; Initialize my error handler $oMyError = ObjEvent("AutoIt.Error","MyErrFunc") $FileName=@ScriptDir & "\Worksheet.xls" if not FileExists($FileName) then Msgbox (0,"Excel File Test","Can't run this test, because it requires an Excel file in "& $FileName) Exit endif $oExcelDoc = ObjGet($FileName) ; Get an Excel Object from an existing filename if IsObj($oExcelDoc) then ; Create a simple GUI for our output GUICreate ( "Embedded ActiveX Test", 640, 580, (@DesktopWidth-640)/2, (@DesktopHeight-580)/2 , $WS_OVERLAPPEDWINDOW + $WS_VISIBLE + $WS_CLIPCHILDREN ) ; Create a test File Menu $GUI_FileMenu = GUICtrlCreateMenu ("&File") $GUI_FileNew = GUICtrlCreateMenuitem ("&New" ,$GUI_FileMenu) $GUI_FileSave = GUICtrlCreateMenuitem ("&Save" ,$GUI_FileMenu) $GUI_FileSaveAs = GUICtrlCreateMenuitem ("Save As..." ,$GUI_FileMenu) $GUI_FileSepa = GUICtrlCreateMenuitem ("" ,$GUI_FileMenu) ; create a separator line $GUI_FileExit = GUICtrlCreateMenuitem ("E&xit" ,$GUI_FileMenu) $GUI_ActiveX = GUICtrlCreateObj ( $oExcelDoc, 30, 90 , 400 , 300 ) GUISetState () ;Show GUI $oExcelDoc.Windows(1).Activate ; I don't think this is necessary. ; GUI Message loop While 1 $msg = GUIGetMsg() Select Case $msg = $GUI_EVENT_CLOSE or $msg = $GUI_FileExit ExitLoop Case $msg = $GUI_FileSave $oExcelDoc.Save ; Save the workbook Case $msg = $GUI_FileSaveAs $NewFileName=FileSaveDialog("Save Worksheet as",@scriptdir,"Excel Files (*.xls)") if not @error and $NewFileName <> "" Then $oExcelDoc.SaveAs($NewFileName) ; Save the workbook under a different name EndIf EndSelect Wend GUIDelete () ; Don't forget to close your workbook, otherwise Excel will stay in memory after the script exits ! $oExcelDoc.Close ; Close the Excel workbook EndIf Exit ; This is my custom error handler Func MyErrFunc() $HexNumber=hex($oMyError.number,8) 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 & $HexNumber & @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 _ ) SetError(1) ; to check for after this function returns Endfunc Excel starts in this script with the 'default' toolbars. To change the excel toolbars or other fancy stuff, you might need to read the VBA help in Excel itself. Those are properties of the Excel Application, not AutoIt. Regards, -Sven

Hello Roman, The 'empty arguments' syntax has been replaced by the 'default' keyword since AutoIt beta version 3.1.1.xx (oops, forgot the exact version number). So the line would be: ; Solution 2: $oObjService.Change(default ,default , default , default , $ServiceStartMode) Regards, -Sven

Hello 'ScriptingSteve', Autoit is not built as being a full fledged OOP (object oriented programming) language. Actually the AutoIt COM/Object support does only 'emulate' OOP-like behaviour. If a function xxxx returns variable type yyyy, it does not mean that you can immediately use a statement like xxxx.zzzz, where zzzz refers to variable type yyyy. You need an intermediate variable to perform this action. To 'convert' your VBscript code to AutoIt code you need to rewrite all nested object-function calls like this: ; conversion for $objParent = ObjGet(ObjGet($objRecordset.Fields("ADsPath")).Parent) $ObjTemp = ObjGet($objRecordset.Fields("ADsPath")) $objParent = ObjGet($ObjTemp.parent) Regards, -Sven

See: http://www.autoitscript.com/forum/index.ph...mp;#entry229092

-Sven

I will move this topic to the 'Support' forum. -Sven

Hello Randallc, The problem is not in the 'Default' argument, but it's about the Order3 argument in de Sort method. Somehow this argument does not seem to be optional in other languages. It is a known issue, see a previous bug report: http://www.autoitscript.com/forum/index.php?showtopic=16157 (Hmm, seemed to be submitted by yourself a year ago?) Your script will work when you replace the Order3 argument with the value 1: .Application.Selection.Sort ($objrange1, $i_Direction1,$objRange2,Default,$i_Direction2,Default,1,Default,2, False,1) Regards, -Sven

This is not a COM Error at all, but a simple typo in the WMI query: The incorrect line is: $objNetworkConfig = $objWMIService.ExecQuery("Select * from Win32_NetworkAdapterConfig") This should be: $objNetworkConfig = $objWMIService.ExecQuery("Select * from Win32_NetworkAdapterConfiguration") Regards, -Sven

Dale is right, the code is too large to isolate the problem. To make it worse: the code doesn't crash when I run it on my computer (Windows XPsp1, english , IE60sp1). I tried several beta versions of the AutoIt3.exe: no crash. Anyhow, I assume the program is not finished: You are defining a GUI in the main script, then adding an Internet Explorer ActiveX control using a local function called LoadWebpage(). However as soon as that function ends, all locally defined variables will be wiped, including your ActiveX control. You will end up with nothing when it returns to the main script. Can you tell me what operating system you are using and which service pack & language, and the version of the internet explorer (including it's patch level)? Regards, -Sven

plastix, A String datatype in Visual Basic is not like a "char *" in C/C++. It is a Wide (Unicode) String type. So your DLLCall should be: $str="DEMO" $init = DllCall($dll,"int","Init","wstr",$str) Your script is not returning the version number, because you use the syntax of DLLCall incorrectly. DLLCall returns an Array, in which element number 0 is the return value of the function. So the second part of the script should be: $Res = DllCall($dll,"str","GetVersion") if not @error then msgbox(0,"version?",$Res[0]) Which will return version 4.0. On the web site of Softuarium I noticed they also offer an ActiveX control version of edcrypt.dll. That would be a better combination with AutoIt, because you don't have to puzzle around with datatypes in DLLcall lines. Regards, -Sven

A very late answer from me. I don't know if the problem has already been solved, but if you look up the error number at www.microsoft.com, it will give you a some possible causes: Error 80020009 = "Exception occurred" This is a generic error message that only indicates that the connection to the database failed. http://support.microsoft.com/kb/q175239/ PRB: 80020009 Error When Retrieving Data from SQL http://support.microsoft.com/?id=216569 PRB: Using the DE Command in a Recordset Causes an Error When you use Google to look up this error code in combination with ADO and .Execute, you will see that it's a very common error message in SQL programming. Regards, -Sven

CrashOverRideZX, It has been fixed in AutoIt beta version 3.1.1.122, but I'm currenly not able to test it. Please confirm if this version has solved your problem. Regards, -Sven

Hello CrashOverRideZX, It took me some time to create a reliable testing environment. Your code relies on interaction with a lot of external objects/interfaces, so I had to be sure I use a clean system for debugging. I have located the problem, but it's difficult to solve. The errors are caused by a safeguard I built in. Because AutoIt is a autonomous scripting language (not embeddeded in the OS, like VBScript), I had to be sure that it is safe for the script to call external functions. One rule in AutoIt developing says: prevent Windows exceptions errors at all cost (we don't like sending automatic error reports to Mr. Microsoft). In this case, when methods or properties of external objects are being called, I check every time if the interface being called supports the IDispatch type interface. If not, the script refuses to use it. Unlike VBScript, which does not make this check at all (In VB/VBA the code knows in advance which objects it's going to use, because it will be pre-compiled). I have checked the automation interfaces derived from Matrikon.OPC.Automation and Matrikon.OPCHDA.Automation. They all support IDispatch properly, but I noticed a weird omission in the interfaces called OPCItem and OPCHDAItem. According to the type library, both are inherited from IDispatch, but they fail with error E_NOINTERFACE when I ask them to give me the IDispatch interface. If I talk 'weirdo language', you can see a visualization of the problem in this screenshot of OleView: I only know of two ways to solve this: A. I disable the safeguard in AutoIt. B. You ask MatrikonOPC to add support for QI IDispatch to these two interfaces. I opt for solution B, because they did implement it properly for their other interfaces. Furthermore, I have never run into this specific problem with any other object. And I can assure you, I have tested many weird automation Objects in AutoIt. -Sven