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

Hi nitro, I made an autoit "ftplugin" for Vim, which I think complements quite well you fantastic autoit syntax file. What it does (for those that do not know much about vim or ftplugins) is that whenever you load an autoit file, it configures some hotkeys to be able to check AutoIt3 syntax, run scripts, compile them, etc. I've set the hotkeys so that they are the same (or as close as possible) to the ones used by Scite4AutoIt: - F2: Show the AutoIt help for the current word (the word under cursor). I could not use F1 since it is already taken by Vim's help file - F5: Run script - Ctrl+F5: Check script syntax using Tylo's AutoIt Checker - :make -> Same as Ctrl+F5, but tries to pipe the output of the checker to Vim - F7: Compile script As a bonus, you can also easily navigate through the defined functions in your script by using the "]]" and "[[" key combinations. It is based on Vim's visual basic ftplugin, and I think that it works quite well, although it has a few shortcomings: - I have not been able to pipe the output of Tylo's autoit checker into the Vim error parser (which can be started by doing Ctrl+F5 or by using the :make command) - I have not been able to get rid of the "windows command prompt" window that appears when you run a script using F5. - When you compile a script with F7, if there are errors the error message is not shown. Other than that I am quite happy with it. Perhaps you can give it a try and if you like it maybe it could be added to Vim's ftplugin list? Also, any help on improving this would be welcome. Scite is not bad, but I'd rather be able to use Vim for all my autoit coding. Cheers, Angel

Hi nobbe, I have just tried your example and it does not seem to work with OpenOffice 3.0. I get the following error: file:///test.doc C:\openoffice_test.au3 (160) : ==> The requested action with this object has failed.: $OO_Doc = $OO_Desktop.loadComponentFromURL($infile, "_blank", 0, $inputargs) $OO_Doc = $OO_Desktop.loadComponentFromURL($infile, "_blank", 0, $inputargs)^ ERROR Do you have any idea why this may be failing, other than the fact that I am using OpenOffice 3.0? Cheers, Angel

Thanks for explaining the technical details Jos. Nevertheless this is something that would be really useful! Hopefully someone could pick the idea and implement it :-) Angel

Hi, I have an autoit compiled script that dynamically generates some autoit script code, saves it into a file and then executes it by calling the compiled script with the /AutoIt3ExecuteScript command line parameter. This works really well except when I try to use the #include statement on the dynamic autoit script code. I expected that if I #included an au3 file in the compiled script, the script that I execute via /AutoIt3ExecuteScript would also have access to it. However this is not the case. Instead it seems that I need to do a FileInstall of the files that I need to include. This seems kind of redundant since the file is already "included" in the compiled script. It is also not so clean since it means that I need to clutter the application folder with these include files. Obviously I don't know the internals of AutoIt and this could be necessary due to the way AutoIt works, but it would be great if you could access the files included in the compiled script when using the /AutoIt3ExecuteScript command line option. Cheers, Amadawn

Actually I did read it, I just misunderstood him ;-) I think he had another comment later on, but he was probably referring to another suggestion, which was to be able to include AutoIt3 executables. I thought he was referring to the inclusion of a3x files as well. Sorry! Angel

OK, so it seems that there is currently no way to do this and also it seems that Valik is quite opposed to it :-( In my opinion this is something that would be quite useful for those of us that cannot always share their source code so it would be great if there was a way to do something like this. Angel

Hi, Is is possible to include an "a3x" file in a regular autoit (.au3) script? That is, I'd like to be able to do #include "my_lib.a3x" in an autoit3 script but I have tried it and it does not seem to work. The reason why I'd like to do this is that we'd like to distribute an au3 library that we made to some of our clients. However we do not want them to be able to see the actual source code for the library, or at least we do not want it to be easy for them to view the code. We just want them to be able to call the AutoIt functions that we made, but not the actual implementation. I understand that if they really want they can probably "de-compile" the a3x file but it just needs to be hard for them to view the code, not completely impossible (mostly to keep our management happy). So, is there some other way to achieve what I want to do? Thanks! Angel P.S.- It is not my decision to hide the code in that library. This comes from my company's management and I cannot do anything about it :-(

MsCreatoR, thanks for the answer. I tried it but it does not work. What these functions do is hide an existing system tray icon. But if the application puts the icon in the system tray again, then it will appear again on the system try. In my case, visual studio puts the icon on the system tray _every time_ that a visual studio macro is executed. So even if I remove the icon (by means of _SysTrayIconRemove), the icon will re-appear again later, which is exactly what I want to avoid. I've found some information on the internet about how windows keeps the info about which icons to show and hide in the registry. It appears that there are two registry keys involved: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify\IconStreams HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify\LastIconStreams These are REG_BINARY keys, and are very big. I tried to read them with RegRead from autoit but it fails. It gives and error code -2: "value type not supported" but the help file says that AutoIt supports REG_BINARY. May this be because their values are too big? What I think that must be done is to somehow change those values so that we can permanently hide the icons. My guess is that visual studio resets that value when it exits (or when it starts) to ensure that the macros tray icon is always shown. So the question seems to be: How can I read and modify those registry values? Any ideas? Angel

Hi, is there any way to always hide the tray icon of an external program? What I want to achieve is the same as if I manually opened the "Taskbar and Start Menu Properties", when to "Customize...", selected a certain program and made it "Always hide". Normally you can do this manually and windows always remembers that settings, but there is an exception: Visual Studio 2005 macros. I have made some Visual Studio macros to automate tasks in Visual Studio 2005. Every time that a macro is running an icon appears on the system tray, showing that a "macro is running". This is very annoying because some of my macros execute every time that a breakpoint is hit in visual studio, so the icon keeps appearing and disappearing from the system tray. For some reason, if I disable the icon, it will remain disabled only until the next time that I start visual studio. It seems that visual studio deletes the "Always hide" setting to ensure that when a macro is running you always get that system tray icon. Is there any way to work around that? Help would be much appreciated! Thanks, Angel

Thanks for the tip guys. This did the trick! :-) Angel