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

Hello CrashOverRideZX, I was trying to run your AutoIt sample code, but I guess I am missing a DLL. The code stops at the line $oHDA.Connect(), stating that it can't find the object with AppID: Matrikon.OPC.DesktopHistorian.1 On www.opcfoundation.com a usercode/password is required to download the software. Could you provide me the missing files? On what line of your sample script did you get the error? What was the exact description of that error? The file opchdaauto.dll seems to be allright for AutoIt: All interfaces are inherited from Idispatch and all properties/methods are defined in the type library. Could be something in AutoIt, but I can't test it. Regards, -Sven

Hello, I haven't been around lately, JPM pointed me kindly to this matter. This problem is difficult to find because the methods of debugging were not very efficient. If one is suspecting problems related to COM, first step is always to use a COM errorhandler for debugging. It will give you a source and a possible description of the error. Secondly, when a COM function fails when it's being called from within a AutoIt statement, the statement itself will also fail. So the method of debugging by using MsgBox(....COMFunction(..)) won't help if you suspect the COM function. If the COM function fails, it would throw a fatal error, stopping script execution; the Msgbox would never appear. A structure of a COM script being debugged could look like this: ; Start of script. ; Step 1: Install a COM Error handler $objError=ObjEvent("AutoIt.Error","yourerrorfunction") ; ...your script here... ; Step 2: Call the suspected function on a separate line $Result=SuspectedCOMFunction(arguments,..) ; Step 3: if the function fails, it would call yourerrorfunction() ; otherwise the script continues to the next line. Msgbox(0,"result of COM function",$Result) .... func yourerrorfunction() Msgbox(0,"error", $objError...etc..) ; See example in helpfile ; It can show you the source of the error, the script line number, error description, etc. endfunc Regards, -Sven

jezzzzy, First of all: In the AutoIt help file, under 'Function Reference->Obj/COM Reference' you can find a chapter that describes 'COM Error handling'. Using that method you can partially 'debug' COM-Related problems. An example for your script: $RemoteComputer="REMOTE"; Change this to your remote computer name $RemoteUsername="REMOTE\Administrator"; Change this to your username on the remote computer $RemotePassword="123456"; Change this to your password on the remote computer ; First install our own Error Handler $oErrObj = ObjEvent("AutoIt.Error","MyErrFunc") ; Open MediaPlayer on a remote computer $oRemoteMedia = ObjCreate("MediaPlayer.MediaPlayer.1",$RemoteComputer,$RemoteUsername,$RemotePassword) if @error then Msgbox(0,"Remote ObjCreate Test","Failed to open remote Object. Error code: " & hex(@error,8)) exit endif Msgbox(0,"Remote Test","ObjCreate() of a remote object successfull !") $Enabled=$oRemoteMedia.IsSoundCardEnabled if not @error then Msgbox(0,"Remote Test","Invoking a method on a remote Object successfull!" & @CRLF & _ "Result of 'IsSoundCardEnabled?': " & $Enabled ) If $Enabled = -1 Then $oRemoteMedia.Open("c:\windows\media\Windows XP Startup.wav") if not @error then Msgbox(0,"Remote Test","Playing sound on a remote computer successful !") EndIf Else Msgbox(0,"Remote Test","Invoking a method on a remote Object Failed !") EndIf Exit ; ------------------------ ; My custom error function Func MyErrFunc() $hexnum=hex($oerrobj.number,8) Msgbox(0,"","We intercepted a COM Error!!" & @CRLF & @CRLF & _ "err.description is: " & $oErrobj.description & @CRLF & _ "err.windescription is: " & $oErrobj.windescription & @CRLF & _ "err.lastdllerror is: " & $oerrobj.lastdllerror & @CRLF & _ "err.scriptline is: " & $oerrobj.scriptline & @CRLF & _ "err.number is: " & $hexnum & @CRLF & _ "err.source is: " & $oerrobj.source & @CRLF & _ "err.helpfile is: " & $oerrobj.helpfile & @CRLF & _ "err.helpcontext is: " & $oerrobj.helpcontext _ ) Seterror($oerrobj.number) EndFunc This code will show you the description of any COM error. To run remote code is getting more difficult lately because of the many MS Security patches, Antivirus software and Firewalls. Many programs are blocking remote code from being executed. The best way is to temporarily disable any antivirus/firewall software. I know, that is 'dangerous', but that would rule out these programs causing the problem. Secondly, check from the LOCAL computer if you can reach the remote computer: 1. by 'ping'ing the remote computer. 2. by checking its status by right-clicking the 'My Computer' icon, choose menu: 'Manage', then menu: Action->Connect to another computer, and enter the remote computer name. If it does not connect to the remote computer, then the problem is not in your script. On the REMOTE computer, you can check if the program you want to control is DCOM (distributed COM) enabled: 1. Click Start button->Settings->Control Panel, Choose: Administrative Tools -> Component Services 2. In the 'Component Services' program, choose: Component Services->Computers->My Computer->DCOM Config. 3. Check in the list of programs, whether your program is visible or not. If not, then you can't control the program remotely. 4. If the program is visible, right click the icon and choose 'properties'. Check if the launch permissions have been set correctly. Hope this helps, Regards, -Sven

Hello neogia, Programming Windows Update (or Software Update Services) is very complicated. One thing you must be aware of is the fact that Microsoft made two API's: One for C++/VB/.NET applications, and another for scripting hosts (VBscript,Cscript). In your examples you are trying to access the C++ API from within a script. That won't work. I can't give you a full solution, but you can find many Windows Update related example scripts at: http://www.microsoft.com/technet/scriptcen...nt/default.mspx Those are VBscript examples, but it should not be too difficult to convert them to AutoIt. I remember someone wrote a VBScript-to-AutoIt converter (can't currently find the post). You can find more information about the Windows Update Agent API at: http://msdn.microsoft.com/library/en-us/wu...rtal_client.asp But keep in mind to use the scripting-interface, not the C++ interfaces. Regards, -Sven

Hello Ptrex, I remembered a similar topic at: http://www.autoitscript.com/forum/index.php?showtopic=14346 Didn't you wrote that example script? I tested that script with 3.1.1.105/106: no problems. (I only added a line GUICtrlSetState($tab0 ,$GUI_SHOW) to show the first tab as default trying to simulate your problem). Then I checked your new script...and rechecked again.. aren't you missing a line GUICtrlCreateTabitem ("") to END the tab definition ?? Because, when I remove the 'end tab definition' from the old example script I get exactly the same behaviour you describe with your current script. -Sven

kjactive, What you are asking for is access to the Type Library of Objects. Currently AutoIt has no native functions to do so. Maybe it will be included in the future, but first I want to get the current COM implementation stable before I add new functionality. You could build a 'plugin' if you are good in C++ COM programming :-) The only way I know to do it using native AutoIt functions is from an idea of Dale Holm (see his amazing discovery at: http://www.autoitscript.com/forum/index.php?showtopic=11466 ) However, that solution requires the tlbinf32.dll file, which is only distributed with MS Visual Studio (as far as I know..). I don't even know whether it is allowed to be distributed separately, but when you 'Google' around, you will find enough links to download this file. Here is a working example using tlbinfo32.dll: ; Example file showing the usage of the TypeLibInformation object (TLI) ; The required DLL (tlbinf32.dll) is distributed with MS Visual Studio ; or use Google to retrieve it. ; ; 2006-01-29 SvenP ; ; More information about the TLI.TLIApplication can be downloaded from: ; http://support.microsoft.com/?scid=kb;en-us;224331&spid=3042&sid=global ; #include <guiconstants.au3> ; We use a Forms2.0 button as an example $oForm = ObjCreate("Forms.Form.1") ; Create a new Forms collection $oForm.caption = "Change properties of this button and click 'Go get info!'" $oForm.Designmode=-1 ; So we can move around with the example button $oForm.ShowToolBox=0 ; Don't show toolbox for this example. ; Create an example button to retrieve info from. $oButton=$oForm.Add("Forms.CommandButton.1","TestButton",1) ; Set some example properties With $oButton .caption="Test Button" .Left=10 .Top=8 .Height=20 .Width=70 .Visible=1 EndWith ; Create a simple GUI for our example GUICreate ( "Embedded ActiveX Test", 460, 480 ) $GUI_ActiveX = GUICtrlCreateObj ( $oForm, 10, 30 , 400 , 180 ) $GUI_Button = GUICtrlCreateButton ( "Go get info!", 10, 215 , 80 , 30 ) $GUI_Edit = GUICtrlCreateEdit ( "", 10, 250 , 400 , 220 ) GUISetState () ;Show GUI While 1 $msg = GUIGetMsg() Select case $msg = $GUI_EVENT_CLOSE ExitLoop case $msg = $GUI_Button ; Note: Example currently FIXED for $oButton variable only ! GUICtrlSetData( $GUI_Edit, ""); clear editbox $aProperties=ObjectGetProperties($oButton) for $Property in $aProperties; Display each property in Editbox GUICtrlSetData( $GUI_Edit, "$oButton." & $Property & "=" & _ Execute( "$oButton." & $Property ) & @CRLF , "append") Next EndSelect Wend GUIDelete () $oButton="" ; Remove the button $oForm="" ; Clear form Exit ; That's all folks Func ObjectGetProperties($oObj) ;DESCRIPTION: Retrieves the description of all writable properties of the given Object. ;REQUIRES: tlbinf32.dll (distributed with Visual Studio) ;PARAMETERS: $oApp - Pointer to an active object ;DATE: 2006-01-29 ;AUTHOR: SvenP ;CREDITS: To Dale Holm Dim $oTLA, $oTLI, $TLIMember, $aProperties[1] Const $cINVOKE_FUNC=1 ; A method (=function) Const $cINVOKE_PROPERTYGET=2 ; Read-only property Const $cINVOKE_PROPERTYPUT=4 ; Read/write property Const $cINVOKE_PROPERTYPUTREF=8 ; Reference property if not IsObj($oObj) then Return $oTLA = ObjCreate("TLI.TLIApplication"); oTLA is a _TLIApplication interface $oTLI = $oTLA.InterfaceInfoFromObject($oObj) ; oTLI is a InterfaceInfo interface For $TLIMember in $oTLI.Members ; This interface contains both methods and properties if $TLIMember.InvokeKind=$cINVOKE_PROPERTYPUT then; Get only WRITABLE properties Redim $aProperties[UBound($aProperties)+1] ; We don't know the number of properties in advance $aProperties[UBound($aProperties)-1]=$TLIMember.Name; Add the name of the property to array. EndIf Next return $aProperties EndFunc

kjactive, Did the revised ObjName() function in beta version 3.1.1.104 solve your problems? -Sven

Hello kjactive, It sounds to me a job for ObjName(). Currently this function only returns the Interface name, or the description of the Object. I could extend this function to return the AppID and/or a CLSID. I'm not sure if returning a DLL name is reliable, because some controls are being 'proxied' through other DLL's. Will that help you? Regards, -Sven

See also this topic: http://www.autoitscript.com/forum/index.ph...11entry138811 -Sven

kjactive, It is advisable always to place a if @error then .... after a ObjCreate() function. Objects are not always available on all computers/Operating Systems. @randallc & Sokko : To see a more descriptive error message about why ObjCreate() failed, you can add a COM ErrorHandler to the script. If you don't know how to do this, kjactive can show you. :-) I don't think the solution in that "Quickbooks" forum applies, because you did not get any error message while 'registering' the OCX with regsvr32. -Sven