Angel

eviltoaster, thank you for your reply. The problem is that ProcessExists("smarquee.exe") returns 0. If I open the task manager the process "smarquee.exe" is not shown either. However, if I select the "Show other users' processes" option then I can see that a process called "smarquee.exe" is running under the "SYSTEM" user. Therefore it seems that ProcessExists is running without the "Show other users's processes" option and I'd like to know if there is a way to change that. While I am accessing the computer remotely (through the "Remote Desktop" feature of Windows XP), the processes I run are being run locally. Cheers, Angel

This does not work for what I want to do, because the screen saver that I want to kill is not the one that would show on my "client" screen, but the one that will show on the "remote" (server) computer's screen. Basically, when you access a remote PC through Windows desktop sharing, the server PC's screen will show a screen saver (while you work on the client PC). Anyway, regardless of the reason why I need to do this, I'd still like to know if there is any way to interact with a process that does not belong to the current user. Obviously, in order to be able to see other user's processes and to be able to kill them the current user would need to have the right permissions (e.g. be an Administrator). Yet, I do not know of any way I can do that with AutoIt even if I run the script as an administrator. Is is possible at all? Thanks, Angel

Hi, I'd like to check if a certain process exists and if it does I'd like to kill it. The problem is that the process I want to kill belongs to the "SYSTEM" user (It is the screen saver, in particular "ssmarque.scr"). Looking at the documentation of the ProcessExists and ProcessClose functions it does not seem to be possible to look for and interact with processes that do not belong to the current user. Is there any other way to achieve what I want (i.e. check if the screen saver is running, and if it is, kill it?). Note that I cannot simply move the mouse to stop the screen saver, because I want to do this while I am accessing the computer through Windows Remote Desktop, and the screen saver that I'd like to kill is the one that is shown in the target machine while I am logged on remotely. Any ideas? Angel

Thank you JohnOne, The thread you linked to is exactly what I was looking for! :-) Angel

Hi, I'd like to know if there is any way to somehow embed Excel into an AutoIt3 GUI (assuming that Excel is installed of course). What I'd like is to show an Excel graph inside an AutoIt3 GUI. The Excel graph can be created by the AutoIt3 script via the Excel COM interface. Is this possible? Thanks! Angel

Thank you. Will give this a try! :-) Angel

Obviously not everything can be in the standard library. But I would argue that Dictonaries are as basic a feature as it comes. If you look at the current standard library there are many packages that seem much less generally useful than a Dictionary package would be. Granted, you can live without dictionaries, but it often means that you end up needlessly complicating your code (using arrays or other tricks instead). I agree that bloat should be avoided, but that does not mean that nothing new should go into the standard library. Is there a process that can be followed to propose adding some new package or function to the standard UDF library?

Thank you M23! In fact that is _exactly_ why I believe that a Dictionary/Hash/AssociativeArray UDF should be added to the standard library. Rather than having people look for one of these implementations or implement their own, just give them one that is proven to work and hopefully as fast as it can get (according to Richard Robertson the one based in Scripting.Dictionary should be faster, but we could easily perform some benchmarking). One could ask why should a Dictionary UDF be added to the standard library and I would argue that the fact that most (if not all) popular scripting languages have it (python, PERL, Javascript and LUA come to mind) indicates that it is not only useful but an expected feature on any scripting language. Since it seems that there are already several good implementations it seems that we would only need to agree on whether it is a good idea to add it to the standard library or not.

I think that a UDF would help in two very important fronts: 1. Discoverability: How many people have wanted to use a dictionary in Autoit and did not know about the "Scripting.Dictionary" solution? How many of those created their own array based implementation? Even among those that found the "Scripting.Dictionary" solution, how many had the same sort of questions about availability and security that I did? Encapsulating this as a standard UDF would solve these issues since people could find it on the AutoIt help file and they would take for granted that the dictionary would "just work", without questioning the actual internal implementation. 2. Initialization: The Dictionary() function that I propose would be able to automatically initialize the dictionary for you based on a 2 optional arrays containing the keys and the values (respectively). It would also be able to take strings as their inputs and automatically call StringSplit() to create the key and value arrays for you. I think that these would be quite useful, specially #1. If you search for "Hash" or "Dictionary" on the AutoIt Track system you'll see that there are a number of requests for a Dictionary object to Autoit. Having one on the standard library would take care of that. My proposal would be for including the following (or a similar) function into a UDF called "Dictionary.au3": ; #FUNCTION# ==================================================================================================================== ; Name...........: _Dictionary ; Description ...: Creates and returns a dictionary object (using the Windows Scripting library). ; Syntax.........: _Dictionary($vKeys=Default, $vValues=Default, $sDelimiterList=Default) ; Parameters ....: $vKeys - An array of key values. ; It can also be a string, in which case the string will be automatically ; split according to the "sDelimiterList" parameter. ; $vValues - An array of values corresponding to each of the keys in the vKey list. ; It can also be a string. ; $sDelimiterList - The characters that will be used to split the vKeys and vValues ; parameters when those are strings rather than arrays. ; Return values .: Success - Dictionary object ; Failure - -1, sets @error to 1 ; Author ........: Angel Ezquerra <angel.ezquerra at gmail dot com> ; Modified.......: ; Remarks .......: ; Related .......: ; Link ..........; ; Example .......; Yes ; =============================================================================================================================== Func _Dictionary($vKeys=Default, $vValues=Default, $sDelimiterList=",") Local $oDict = ObjCreate("Scripting.Dictionary") If @error Then SetError(1) Return 0 EndIf If $vKeys <> Default Then Local $nFirstElement = 0 If IsString($vKeys) Then $nFirstElement = 1 $vKeys = StringSplit($vKeys, $sDelimiterList) EndIf If $vValues == Default Then Local $vTemp[UBound($vValues)-$nFirstElement] $vValues = $vTemp ElseIf IsString($vValues) Then $vValues = StringSplit($vValues, $sDelimiterList) If $nFirstElement == 0 Then Local $vTemp[UBound($vValues)-1] For $n = 0 To UBound($vTemp) $vTemp[$n] = $vValues[$n+1] Next EndIf EndIf ReDim $vValues[UBound($vKeys)] For $n = $nFirstElement To UBound($vKeys)-1 $oDict.Item($vKeys[$n]) = $vValues[$n] Next EndIf Return $oDict EndFunc

Thanks a lot! I want to avoid tying my code to certain versions of windows, but it seems that it should be quite safe to use. Then, wouldn't it make sense to create a UDF library to create dictionaries? It would be very nice to have a standard way of creating dictionaries in AutoIt. Cheers, Angel

Thanks for the (quick! :-)) answer Richard! Do you know whether it requires some additional DLL or library to be installed in WindowsXP and/or Vista/7? Cheers, Angel

I often miss a having a built-in dictionary type in AutoIt. After looking for information on how to implement my own I found that one of the proposed solutions is to use ObjCreate() to create a "Scripting.Dictionary" object. While I've used ObjCreate() before to access COM objects from AutoIt, I have never used the "Scripting" library (if that is the proper name). My question is how "safe" it is to use this library. By safe I mean whether the library and in particular the Dictionary class is available on all versions of windows and whether some particular DLL or windows component needs to be installed to be able to use it (e.g. does it need some visual basic DLL?). That is, can I assume that I'll be able to access the Scripting.Dictionary class on all Windows machines (including different language versions)? I would also like to know whether there are any security/permission issues related to using the scripting library. In particular, does the autoit script need to be run as an administrator? Will it trigger the User Account Control on Windows Vista and Windows 7? Finally, are there any speed/performance issues using this? How much slower is accessing a Dictionary element than accessing a regular AutoIt array? I understand that I should not bother much about speed when using a scripting language such as AutoIt, but I would like to know if I need to be specially careful when using this. If this is safe, fast and is available on all versions of windows, wouldn't it make sense to be added as a UDF with AutoIt? Thank you in advance, Angel

Thanks a lot Lazycat! You are definitelly not a lazy cat at all! :-) Angel

Thanks a lot. I somehow had missed that function when I looked for it on the help, even though I was expecting finding a function with a similar name. But I would like to still continue with the question. What I would like to know is whether there is a more "generic" way to change the text on a control on one of your own GUIs. Preferably, I'd like to find a method that does not require you including the include corresponding to each of the types of GUI controls that you may use on your GUI. For instance, is it valid to pass @GUI_WinHandle to the window name of the ControlSetText() function? I tried it and it worked, but is it safe to use? That is, is ControlSetText (and the other ControlSet functions) supposed to be able to accept a window handle in stead of the regular window name parameter? Thanks, Angel

Hi, I have an AutoIt3 script which creates a simple GUI in which there is an editbox and a button. When I click the button I would like to change the text in the editbox. I know that this is a really simple scenario and that probably the answer is straightforward, but, is there a better way than using ControlSetText()? The reason I ask is that using ControlSetText seems to be "out of place" among all the other calls to the GUICTrlXXXX functions, since you must give the name and the text in the window where you want to change the text as if you were changing the text on a window on an external program. Currently I am simply calling ControlSetText with empty strings for the window name and text, but I feel this is not very same since I believe that doing that will look for the control on the current active window, which may not necesarily be the window in which the button that generated the event is placed. So, is there some better way to handle this sort of situation? Thanks a lot for your suggestions, Amadawn