Angel

Hi guys, is there a simple (or even a complex ) way to append text to the end of an edit box, regardless of the caret position? I want to be able to do this without scrolling down to the bottom as I want to be able to append some text while the user is looking at the top of the edit box. I currently use the following code to append the text: GUICtrlSetData ($logCtrlId, $text & @CRLF, 1) Right now, if the user clicked somewhere on the Edit box, changing the caret position from the end to some other part in the middle of the text, the next time I append some text it is added where the caret position is. Instead I'd like to always append the text to the last line of the edit box. Is this possible? Thanks, Angel

I also want to thank you guys, of course! I was really waiting for this! Let me suggest that you all take a well deserved break and enjoy the moment. I've been using the latest betas and they are awesome. I'll try the new version once it is properly updated (when I download it the installer says that it is version 3.1.1). Now, let me be the first to ask... what do you guys have planned for the future? Perhaps some sort of debugging capabilities? That would be awesome, as it is the only thing that I really miss in AutoIt. What do you have in store for us? Cheers, and congratulations! Angel

Hi, I just learnt that the new official version of AutoIt3, 3.2.0 has been released! So I headed to the download area and downloaded it, but when I run the installer it says that it is version 3.1.1! Is that normal? I'd also like to thank you guys for all your great work! It's taken a long time, but if this is as good as the last betas, it was really worth the wait! Thanks! Angel

Hi, I have a function with a single parameter. That parameter has a default value. Therefore it can be called without any parameters. This made me think that I can use this function as the "OnEvent" function of one of the elements of my GUI. However, when I do that and the function is run after the corresponding event, I get an error telling me that the variable corresponding to the argument does not exist. Is that normal or is it a bug? Thanks! Angel

Hi, Is it possible to save the indentation settings in Scite? I guess it must be possible, and probably evident, but I cannot find how to do this! Every time that I open a new file or that I close Scite the indentation settings change back to 4 spaces and "use tabs" (bad, bad, bad! ) By the way, is there some easy way to add some buttons to the Scite toolbar? I'd love to add a button for "check script syntax", one for run script and another one for compling the script. Thanks! Angel

If the other computer has Windows 2000 while yours has Windows XP, then the reason is probably that the comboboxes have different behaviours in 2000 and XP. In XP they "autosize" while in 2000 they honor the size that you set when you create them. Try changing the "height" of the combobox and see if it works better. Cheers, Angel P.S.- Thanks to Larry who explained this to me in the first place. BTW it is explained in the AutoIt GUI help but it is not very clear.

Yeah, I hoped that someone had already done this in the past and I was in quite a hurry to finish my script. That is why I asked in "Scripts and Scraps". It seems however that I might have more time than I thought to finish the script, so I guess I'll have to take time to do it myself! If I do I'll post the result here. Angel

Hi, I know that this is very easy to do, but I am in a hurry so I thought that I might just ask to see if someone did this in the past. I apologize in advance! Has anyone ever done a script that checks if a window is completelly visible, that is, that it is totally inside the boundaries of the screen and that no other windows (including the windows taskbar) is obstructing it? If someone has, could he/she please post the script in this forum? Thanks!!! Angel

Thanks a lot gafrost. You are the ! I looked for "process details" on the forum but I did not find these useful threads! It'd be great if these functions made it as UDF into the "Process.au3" library! I have a question though. What is the difference between using the wmi and using a call to kernel32.dll in WindowsNT (and I assume XP) systems? Would the wmi method work on older windows systems (such as 95 or 98), of which we still have some on the lab? Does the wmi method rely in some service or some user privileges to run? Would an antispyware tool block this? I ask because I want to make this as transparent to our users as possible. Thanks, Angel

Hi, I have a java program that sometimes fails to close properly. Its window is closed but the corresponding process doesn't die. So whenever the user opens it up again it does not work properly (the program needs to communicate through the serial port, but the port is blocked). I could easily make a small autoitscript that looks for javaw.exe and kills it. However I don't feel that it is safe, as the user could be running another unrelated java program and the script would kill it. By using SysInternal's ProcessExplorer I can see the "zombie" process and I can get a lot of information about it, notable the actual path to the javaw.exe executable that was run. If I could get this info with AutoIt I would be able to distinguish betweeen that javaw.exe and any other one. So, is there some way to get the full program path from a running process in AutoIt? Any help would be greatly appreciated. Thanks! Angel

Thanks a lot guys, that made the trick! I did not see that info on the help file! It is there, but it is hardly noticeable (I wish it was in bold red letters! ) Thanks! Angel P.S.- Sorry for the late answer (long vacation!)

Hi, I have made a GUI that has a combo list. I am trying to use the dropdown list of the combo to put the history of filenames that the user puts in the combo control. Thanks to the help on this forum, I learned about the "_GUICtrlComboGetList" function and I got my history working great on WindowsXP. However, when I try to run my same program in Windows 2000 the "history" is empty. That is, there are no items in the combo control list. So I'd like to know if there are any known issues or differeences with Combo boxes in Windows 2000 vs XP. I am using GuiCtrlSetData to update the items in the combo list. Any ideas? Thanks, Angel

Thanks! That works great! Angel

Hi, I've looked on the help and on the forums. Sorry if this is evident for you guys. There is not a GuiCtrlGetData counterpart to GuiCtrlSetData. For comboboxes I can use GuiCtrlSetData to set the list of items on the combobox and GuiCtrlRead to get the current item, but I cannot get the list of items from the combobox (or at least I don't know how). I am trying to create a "history" combobox which I want to update on the fly. Before exiting my application I want to save that list of items (the latest history) into the registry, but I don't know how to read the combo item list. Any help? Thanks!!! Angel

And why use AutoIt when you can use C++?! :"> It is of course a matter of simplicity. I use AutoIt because it usually lets me do a lot of neat stuff with very little effort. If I need to start writing tens of lines of coude just to color a button then the whole purpose of using AutoIt becomes kind of moot... I just believe that this is such a basic thing, used in so many programs that it should either be included as an official UDF or, preferably, as a built-in feature of AutoIt. Angel

I actually think that this functionality MUST be part of the AutoIt GUI feature set. Making a colored button shouldn't be a matter of "black magic" as it is right now! That may be understandable to make other sorts of "fancy" buttons (with images, etc) but not to make a button with green text, for instance (and even a basic image button should be implemented in AutoIt, in my opinion). Perhaps this should be filed as an open bug? Angel

Where can I see that list? Angel

I hate to ask this, but I LOOOONG time ago the new release was supposed to be "Real Soon Now " or "As soon as Jon has some time". So what happened? The betas keep coming, so the development is quite active... are there any major bugs that are holding the new release? I'd just like to have an idea of what is going on, as I have no access to the developper discussions... Thanks! Angel

Wow, I wish I could help you but I really would not know where to start, never having used XML beofre, but this sure would make Koda the perfect GUI tool for AutoIt3! I will check Kodawrapper, but having this builtin into Koda would be perfect! Can Kodawrapper be used with Scite? Sorry, I never heard of this before... I didn't want you to do this for non string variables. I realized that this would be very hard and that it did not make so much sense anyway :-) Cheers, Angel P.S.- Again, thanks for writing this really cool tool!

Oh! And let me be even more ambitious (it is easy, as I am not the one doing the work! :"> ). Please bear with me and just tell me if you think that this is too far fetched (I realize that this could probably not be implemented soon, so it is just a suggestion for the future development of Koda). What if you could somehow tell Koda that the value that you put in one of the properties (in the property editor) must be used "as is"? That is, what if I could put some "AutoIt3 code" embedded into one of the GUI properties? Actually, today I can achieve this behaviour with the following trick: - Set the property to: " & $MY_VALUE & " (note that I actually need the quotes in the property. - The resulting code is: GUICtrlCreateInput("" & $MY_VALUE & "", 136, 136, 441, 24) Which actually achieves what I want, that is, to set the default string in the Editbox to the contents of the $MY_VALUE variable. Of course, I need to first make sure that I have defined $MY_VALUE in the code before the KODA generated code). The problem with this trick is that it only works with Text Properties (which is probably not a big deal, as these are the ones in which this kind of trick would be more useful anyway). Also the extra "" & and & "" seem unnecessary. So what I propose is that Koda could detect that I am using " in the beginning and the end of my property and remove it when it generates the code. This means that " would become some sort of "escape character" which tells Koda to embed whaterver I put in the property as if it was AutoIt3 code. The resulting generated code for my example would be: GUICtrlCreateInput($MY_VALUE, 136, 136, 441, 24) Of course I realize that this could give a few (perhaps a lot of) problems! In particular, what if you try to run the code from Koda? Many of the problems could be fixed by: - allowing the use of this "escape character" only for a small set of properties where it meaks sense (mainly the "Text" and "Caption" properties) - using default values when Koda cannot evaluate a value - adding the notion of "init code" to Koda: This would be some code that is exectuted at the beginning of the script and where you can initialize any variables that you use in the Koda properties. This could could be saved on the Form file so that when you open the form with Koda again this code is used to populate the Form that is presented in the Koda editor. OK, that is is. As I say it can be done (with a bit of work) today. But it could be a nice future improvement, specially coupled with the Init code. Thanks for reading this lenghy post! Angel

I have one more suggestion for Koda (I don't know if someone else said this already). Please forgive me if it has already been discussed or if you think that this is out of the scope of your project. The only realy problem that I have with Koda right now (specially now that you're going to add OnEvent support) is that it is hard to use Koda to update an existing GUI, even if it was generated with Koda. I'd be cool to be able to use Koda and Scite to directly update the GUI code in a script. What I imagine is that perhaps Koda could add some lines around the code that it generates, and then you could have an "update button" that instead of creating a new file it would only update any code within the "Koda" lines. In this case the user could write the code outside the "Koda code" in his scripts and still use Koda to update that part of the code for you. When using this "update mode" Koda would not need to generate the GUI message loop only, only the GUI creation code. And, when using Events, this wouldn't even be a problem, as the Msg loop is not used anymore... What do you think? Cheers! Angel

I think that you understood me, but I re-read my post and I forgot to say the word "Font". That is, I meant that the only property that has sub-properties is Fonts and I'd like it to rememember its unfolded state (or, if it cannot be rememebered, be always unfolded by default). As for the Events names, I think that now I understand the problem. So I'd suggest using the "default" event for each control type: - onclick for Checkboxes and Buttons - onchange for Editboxes and comboboxes (I know that for some comboboxes an event is fired when clicking on a different element, but that actually changes the current value). Actually, checkboxes could either be onclick or onchange (both are the same). I don't know what would be better for other GUI controls... Another alternative is to just use OnEvent. If in the future it is changed in AutoIt3 (that is, if new events are added) the new Koda could just read OnEvent and assign it to the "default" event (wich for buttons would be click, etc). I hope what I mean is clear... Thanks! I looking forward to the newer version! You should tell the Scite4AutoIt folks when you have it ready so that they update their installer as well!!! Angel

Are you sure that "onclick" is the best name? For instance in EditBoxes it is not "onclick" but "onchange", right? So why not just use "OnEvent", as the corresponding AutoIt GUI function? BTW, this is really great! I hope you implement this soon! Also, I'd like to make a small request. Currently the only property that has "sub-properties". Right now it is always unfolded by default. Whenever I select a new GUI control it gets folder again. I'd be great if it could either always stay unfolded or at least remember the last state (folded/unfolded). Thanks! Angel

My main wish for Koda and the reason why I only use it sometimes right now is to be able to use "Callbacks" (i.e. GuiCtrlSetOnEvent) instead of a message loop for the Event handling. I'd like to be able to set the name of the Event function in Koda itself and then when I generate the code I'd like Koda to put calls to GuiCtrlSetOnEvent on the auto generated code. If Koda did that it'd be fantastic! Angel

The problem is that I don't really have access to an instrument that uses RS-232 (while I have access to GPIB instruments). Have you had a look at the library functions. There I basically just followed what the VISA spec says, but perhaps I made some mistake on the ASRL (serial) part. Maybe you could have a look as I cannot really test it on my own Angel