ChrisJakarta

@AdmiralAlkex Thanks for giving me the confidence to report this as a bug. I did so, and there was an immediate response to say it will be corrected in v3.3.9.0. Chris

I had been waiting patiently for changes to the object programming in v3.3.8.0, hoping that they would address this problem. Sad to say, this does not appear to be the case - the problem of passing booleans still remains. Has anybody any ideas of a work around? Is this a bug (as it appears to me to be)? Until this is addressed, I will not be able to migrate my programs from Word to OpenOffice/LibreOffice... Chris

Thanks for the swift response. Yes, I guess I should try to find the time to investigate further, although at this stage I'm not sure how I'd start. One of the problems with investigating further (and perhaps the reason for the additional question) was that there is no slow-down in the response when running the un-compiled script. I'm not sure what that suggests. But I was rather hoping to find out if anyone else had experienced problems before digging deeper. Thanks. That's rather what I expected. But I guess I don't quite see what the problem would be excluding all autoit build executables from a virus scan, since I can be confident that they are not infected. Chris

Since upgrading to the latest version of Microsoft Security Essentials (MSE) v2.1.1116.0, I have found that at least one of my compiled scripts runs very slow. I cannot be sure that MSE is the cause (it might perhaps be one of the recent Windows updates, although it is the same on my XP desktop and my Win7-32 notebook), but adding the .exe file to the Excluded files list in MSE solves the problem. Has anybody else experienced this? Is there a way to exclude all AutoIt compiled programs, for example by listing a .dll? Chris

Dale, Thanks for the idea. However, as you suspected, it doesn't seem to help. The VBS definition of True appears to be 0Xffffffff, but I'm not sure how that might be implemented in AutoIt. I've also tried Running the VBS script from AutoIt, which (perhaps unsurprisingly) works. But I don't know how to pass and retrieve parameters to an external script (if it is possible, which I doubt), so that doesn't help me. Not sure where to go from here. Is it correct to call this a bug? Chris

Yes, indeed. I tired just about every combination I could think of Sorry, I missed that. But it does seem that this is a well-documented and quite long standing bug, if rather arcane. But it is essential for successful automation of Open Office. Is there a way it can be escalated? Chris

I have been trying to implement programming of Open Office through AutoIt. Open Office requires the passing of an object to its loadComponentFromURL function. This object consists of a Name and a Value, and is used to pass various information on the file, such as password (passes a string value) and Readonly (passes a boolean). I have implemented a function to set up this up, based on several examples in these forums. However, I find that while this passes strings OK, it apparently cannot be used to set boolean values to true - whatever I try, it stays as false. Here's a quick and dirty example which demonstrates this: Dim $OpenPar ; This returns object with both fields correct $OpenPar = MakePropertyValue("Password", "secret") ; This returns object with value False as requested $OpenPar = MakePropertyValue("ReadOnly", False) ; This returns object with Vlue False, not True as reuqested $OpenPar = MakePropertyValue("ReadOnly", True) Exit Func MakePropertyValue($cName, $uValue) $oSM = Objcreate("com.sun.star.ServiceManager") $oPropertyValue = $oSM.Bridge_GetStruct("com.sun.star.beans.PropertyValue") $oPropertyValue.Name = $cName $oPropertyValue.Value = $uValue MsgBox(0,$oPropertyValue.Name,$oPropertyValue.Value) $setOOoProp = $oPropertyValue Return $setOOoProp EndFunc Has anyone any idea why this does not work correctly (the vbs version works perfectly)? Am I facing a bug, or is there something I'm doing wrong? Chris

I've done a little more investigation into the problems of passing the parameters. It seems that there is no problem in passing strings (e.g. "Password"); I have not yet tested passing integers. But there is clearly a problem in passing Booleans. If $uValue is passed as True (without quotes), this is passed to MakePropertyValue as a Boolean, but $oPropertyValue.Value remains False; it is not possible to change it to True. If it is passed as "True" (with quotes), it is passed as a string, is stored as a string with value "True', but this has no effect on the result of loadComponentFromURL. I have tried passing the parameter as an integer with value 1 or value 127 (since OO stores Booleans as 2 bytes, with True non-zero), but this still has no effect. I'm running out of ideas.It does not seem passible for this routine to pass a parameter with value True. As I say, VBS has no problem. Anyone offer any help? Chris

I've been trying to work with this and similar UDFs to automate OpenOffice, but I'm finding that the setProp function does not seem to work. For example, setting $OpenPar to "ReadOnly" has no effect, and as far as I can determine, the same is true for all parameters set by this function. I have tried essentially the same function in Visual Basic, and it works, so it doesn't seem to be a problem with my installation of Open Office. I have also tried with a much earlier version of AutoIt3, with the same result. I note that at least an earlier version of a similar UDF sets the parameter with: $OpenPar[0] = _ArrayCreate(setProp("ReadOnly", True)) {_ArrayCreate is an apparently depreciated function in the Array UDF). This does not seem to make any difference. What am I missing? I am by no means clear on how these object programming needs are implemented in Autoit, so I'd be grateful for any clarification/ Thanks Chris

Can anyone explain why, if I have not logged in, I do not see the Smileys? Instead I just see the link, e.g. (IMG:http://www.autoitscript.com/forum/style_emoticons/autoit/biggrin.gif). Not a huge problem, but surprising! Perhaps I am more aware of this since I have to log into the forum every time; even though it remembers my login/password, it does not automatically log in in as most such forums do. I have been unable to find a way to stay logged in... Chris

Sorry, I tried several times to make this work, but without success. I'd be really grateful for a brief example... Thanks Chris

I occasionally have problems connecting to the server. Is there any way to add a time-out to the _FTPConnect() function, to stop the program going into never-never land? Grateful for any ideas... Chris

dbzfanatic, Thanks for the idea. From this seed, I offer the following solution, based upon the Editbox example: ; External Editor ; ; Author: Chris Green ; ; Based on EditBox example by: ; Author: "SlimShady" ; ;Include constants, etc #include <GUIConstantsEx.au3> #include <Constants.au3> #include <File.au3> #include <ButtonConstants.au3> Opt('MustDeclareVars', 1) _Main() Func ExtEdit($edit_id) Local $file, $text, $tfname, $tfpath, $szDrive, $szDir, $szFName, $szExt, $title Dim $tfar[5] $text = GuiCtrlRead($edit_id) $tfpath = _TempFile("","",".txt") $tfar = _PathSplit($tfpath,$szDrive, $szDir, $szFName, $szExt) $tfname = $tfar[3] & $tfar[4] $file = FileOpen($tfpath,2) If $file = -1 Then MsgBox(0, "Error", "Unable to open file.") Exit EndIf FileWrite($file,$text) FileClose($file) ShellExecute($tfpath) Sleep(1000) $title = WinGetTitle("[active]") WinWaitClose($title) $file = FileOpen($tfpath,0) $text = FileRead($file) GUICtrlSetBkColor($edit_id, $COLOR_YELLOW) WinActivate("New GUI") GuiCtrlSetData($edit_id,$text) Sleep(1000) GUICtrlSetBkColor($edit_id, $CLR_NONE) FileClose($file) FileDelete($tfpath) EndFunc ;==>ExtEdit Func _Main() ;Initialize variables Local $GUIWidth = 300, $GUIHeight = 250 Local $Edit_1, $OK_Btn, $Cancel_Btn, $Edit_Btn, $msg #forceref $Edit_1 ;Create window GUICreate("New GUI", $GUIWidth, $GUIHeight) ;Create an edit box with no text in it $Edit_1 = GUICtrlCreateEdit("", 10, 10, 280, 190) ;Create an "OK" button $OK_Btn = GUICtrlCreateButton("OK", 40, 210, 70, 25) ;Create a "CANCEL" button $Cancel_Btn = GUICtrlCreateButton("Cancel", 200, 210, 70, 25) ;Create a "EDIT" button $Edit_Btn = GUICtrlCreateButton("Edit", 120, 210, 70, 25) ;Show window/Make the window visible GUISetState(@SW_SHOW) ;Loop until: ;- user presses Esc ;- user presses Alt+F4 ;- user clicks the close button ;- user clicks the Cancel button While 1 ;After every loop check if the user clicked something in the GUI window $msg = GUIGetMsg() Select ;Check if user clicked on the close button Case $msg = $GUI_EVENT_CLOSE ;Destroy the GUI including the controls GUIDelete() ;Exit the script Exit ;Check if user clicked on the "OK" button Case $msg = $OK_Btn MsgBox(64, "New GUI", GuiCtrlRead($Edit_1)) ;Check if user clicked on the "CANCEL" button Case $msg = $Cancel_Btn Exit Case $msg = $Edit_Btn ExtEdit($Edit_1) EndSelect WEnd EndFunc ;==>_Main Hopefully this might be useful to others. It should be generic for any text editor that is associated with the '.txt' extension. Chris

Is there any way to link an edit control to an external editor (I use TextPad), similar to the "It's All Text!" extension in FireFox? The intent is to be able to click a button on the GUI which would transfer the text to the external editor, where it could be edited with all the additional functionality of the editor, then when complete, saved in the external editor, returning the edited text back to the edit control. Chris

Earlier posted an apparent problem. Turns out the problem was with my code - sorry. However, I think the parameter problem remains Chris

Seems like you made the changes in a rush again I think the parameter in Func _FTPFileFindClose($h_Handle) (line 464) should be $l_FTPSession, no? With that change, my code compiles OK. I think you've also got a couple of other references to $h_Handle in the comments (see lines 369 and 456) which probably need to change. Chris

Thanks - I was beginning to think this UDF was dying by degrees. Seems that the variable $handles on line 322 should read $s_handles, no? With that changed (corrected?) this version seem to work fine for me, although only with a subset of the functions. Chris

That's a great offer - thanks! I've just checked it out, and it seems the following two functions are those I would like to see: _ExcelSheetUsedRangeGet() _ExcelFindInRange() But I can manage with the 'old' version, so it's not urgent... Again, thanks Chris

May we asssume this new version is fully compatible with the the last version of ExcelCOM_UDF? So that all we need to do is change the include name? Thanks Chris

If I run the bare v.3.12.0, the compiler finds @unicode, but with the full SciTE also installed, it fails to find it. It does however find @AutoItUnicode. Not sure why that should be, but perhaps there's some setting in the full editor which I haven't found... Chris

I have deleted the latest AutoIt version and reinstalled v3.2.8.1. This still runs OK for me, and does not trigger AVG... Chris

Done Chris

The most recent virus database update to AVG marks AutoitSC.bin as infected with Downloader.Agent.AEPV. The earlier version in v 3.2.8.1 gives no problem. Checked with virusscan.jotti.org, AVG the only virsu program indicating problems. BTW, to update the Sticky, for AVG see <http://forum.grisoft.cz/freeforum/read.php?4,104930,backpage=,sv=> Chris

Thanks, Locodarwin, v1.4 seems to correct my problem with _ExcelFindInRange. One other comment if I may: If a workbook is opened as hidden ($fVisible = 0), and subsequently an error occurs so that the workbook is not properly closed, I have found no way to close it or re-open it without forcing Excel to close or re-booting. Am I missing something? Perhaps an error handler is needed to trap this? In the meantime, I've tried to include appropriate error handling in the calling routine.... Chris

Thanks for a very useful set of routines. However, I did experience a couple of problems, one significant (assuming I go the latest version: v1.32, 02-12-07): 1. _ExcelFindInRange calls the Excel routine ".Selection.Find". I have found the last parameter of this ($fMatchFormat in the UDF, MatchByte in the Excel routine) must be removed. In the Excel VB Help file, it states: "Used only if youve selected or installed double-byte language support." Not sure what that means, and perhasp its a problem because I'm still using Excel 2000, but including this parameter caused failure. Deleting ",$fMatchFormat" in several places in the UDF seemed to be the only solution. As far as I can see, this does not harm. 2. (Nit-picking) In the description of _ExcelBookSaveAs, the syntax shows "_ExcelSaveDocAs". You may wish to correct this. Chris