tns1

I noticed that for Acrobat 5, ActiveX/COM Inspector does not show anything in the running COM object window which is confusing since it looks like Acrobat 5 does have a COM interface and AutoIt scripts can do things like: (from posted code) $SourcePDF = ObjCreate("AcroExch.PDDoc") $SourcePDF.InsertPages() $SourcePDF.Save() $SourcePDF.Close Also, I can drill down in the right pane of ACI and see: Adobe Acrobat 5.0 Type Library->DispInterfaces->CAcroPDDoc.InsertPages() including the various parameters The question is, once I have examined the library and found a method like InsertPages() that I'd like to use, how do I know to use ObjCreate("AcroExch.PDDoc") to get at that method? The string "AcroExch" does not appear in the library, so where is this mapping made?

OK, I downloaded the ActiveX/COM Inspector and I see what you mean. Looking at things dynamically shows what is going on at the time. Still, if I wanted a comprehensive list of every method and property I would expect to be able to get that by examining the lib directly. I think these other tools should let me do that, I just haven't figured it out. What I have been after is a better understanding of COM so that I could spin my own COM enabled autoit scripts as needed. I have written a small app using ExcelCOM_UDF and I ran across the situation where the low level call to $oExcel.Selection.Find() and $oExcel.Selection.Replace() does not work as expected with Excel 2000 but it does with Excel 2003. I needed to see what the COM interface really looked like for these calls. If I am reading it right, the Inspector shows these calls to have fewer parameters with Excel 2000.

Well, Application.Selection just shows as an object without any way to drill further, whereas Application.SendKeys() is clearly a method with two parameters. That is what I am expecting to see. I admit the concepts are a bit fuzzy to me, but the COM objects that allow you to monkey with a spreadsheet are not part of the spreadsheet itself are they? If you take an xls file and drop in onto a machine without excel installed, you won't be able to use COM on it. Those methods are defined as part of an exe, dll, olb or other file. If thats the case, then every parameter list for every method has to be defined in this file doesn't it? Besides, the tool (TLV) is setup to point at files, not running processes....

I am trying to see the methods and parameter lists using any of the above tools but I am getting lost. For instance, I am browsing the excelcom_udf and I see calls like: $oExcel.Selection.Find(etc,,,,) or $oExcel.Selection.Replace(etc,,,,) I should be able to point the TLV tool at EXCEL9.olb and drill down to see the same method name and parameter list, but how? Problem is there is a lot of info, and a lot of entries that kinda look like they would apply but don't match.

CODE;=============================================================================== ; ; Description: Returns Excel Version String ; Syntax: $sVersion = _ExcelBookNew($oExcel) ; Parameter(s): None ; Requirement(s): None ; Return Value(s): On Success - Returns 8,9,10,11 ; On Failure - Returns 0 and sets @error on errors: ; @error=1 - Specified object does not exist ; Author(s): ; Note(s): None ; ; _ExcelVersion() ;=============================================================================== Func _ExcelVersion($oExcel) If NOT IsObj($oExcel) Then Return SetError(1, 0, 0) $iVer = Int(Number($oExcel.Application.Version)) ;Version 8 = '97, 9 - 2000, 10 - XP, 11 - 2003 If $iVer >=8 AND $iVer <=11 Then Return $iVer Endif Return 0 EndFunc ;==>_ExcelVersion In my limited testing, there appear to be some different behaviors and differences in parameter requirements between different versions of Excel. For instance in the FindReplace CODE;version difference between 2000 and 2003 If _ExcelVersion($oExcel) = 9 Then $oExcel.Selection.Replace($sFindWhat, $sReplaceWith, $iWholeOrPart, Default, $fMatchCase) Else $oExcel.Selection.Replace($sFindWhat, $sReplaceWith, $iWholeOrPart, Default, $fMatchCase, Default, $fMatchFormat, $fReplaceFormat) ElseIf Also 2003 will produce a warning dialog if a replace string is not found, where 2000 does not. Can this be suppressed?

I really like that video. It shows how easy it is to hand off your personal info to some stranger's website . Won't greasemonkey+autoit allow you to create this type of function all on your own machine? If not, why not?

I got it working by removing the last 3 parameters from the call: $oExcel.Selection.Replace($sFindWhat, $sReplaceWith, $iWholeOrPart, Default, $fMatchCase) ; , Default, $fMatchFormat, $fReplaceFormat) I first created a macro in Excel to do the same thing and then examined it in VBE - it didn't show those extra parms. Does this mean they don't exist in my version of Excel or what? Working code: $oExcel = _ExcelBookOpen("my.xls", 1, False) _ExcelReplaceInRange($oExcel, "FIND", "REPLACED", "A1:T20", 1, 1, 1, 2, True, False, False) _ExcelBookClose($oExcel, 1, 0)

The range selection is working, just not the replace. Just to be clear on this, is a beta release still needed for the ExcelCOM_UDF? Autoit v3.2.4.9 has everything that Beta 3.2.1.12 had doesn't it?

ExcelCOM 1.32 with AutoIt v3.2.4.9, Excel 2000, WinXP Can't get the _ExcelReplaceInRange() to work. I just get a general error dialog with no hint of the problen on this line: $oExcel.Selection.Replace($sFindWhat, $sReplaceWith, $iWholeOrPart, Default, $fMatchCase, Default, $fMatchFormat, $fReplaceFormat) Tried a few different things - some test code: $oExcel = _ExcelBookOpen("my.xls", 1, False) ;$msg = _ExcelReplaceInRange($oExcel, "FIND", "REPLACED", 1, 1, 10, 10, 2, True, False, False) $msg = _ExcelReplaceInRange($oExcel, "FIND", "REPLACED", "A1:T20" , 1, 1, 1, 2, True, False, False) If $msg = 0 Then MsgBox(0, "Error", "@error = " & @error) EndIf _ExcelBookClose($oExcel, 1, 0) See anything?