Caravelle

Thanks to Blue_Drache. I'll try, and see what happens, though I have it working now with TJ123's simple solution (even if I don't understand why it works). Thanks to Mechaflash, though I'm not sure what you're saying. I tried !y (see my original post). The Button isn't on the BaseStation window, it's on a modal MessageBox called "Confirm". And we know that "BaseStation SBS1" works as a Window name, otherwise it would not produce the "Confirm" MessageBox when the script tries to close it. And thanks to JohnOne, who wrote "'WinWaitActive("Confirm", "Do you really want to shut BaseStation down?")' is the culprit, the window is either not becoming active or it is not being detected." I tried it with and without the text attribute. Strange that the script works with TJ123's answer, which suggests that the window is indeed being detected and becoming active, it just won't respond to the usual Send() commands in a straightforward way. Oh well. Caravelle Caravelle

Thanks to all. John wrote: The script is as you saw it, the looping bit will be added later. It does not exit, it's waiting for something. Somdcomputerguy wrote: It may... but nothing I've tried so far has worked. I tried the following without any luck: ControlSend ( "Confirm", "", 2393982, "y")ControlClick("Confirm", "", "[ID:2393982]")ControlClick("Confirm", "", 2393982)ControlClick("Confirm", "", "[CLASS:TButton; TEXT:&Yes; INSTANCE:2]")Finally, in desperation, I tried MouseClick("left", 600, 436)and it worked. This would be a practical solution as if no-one touches the laptop while I'm away the confirm dialog will always appear in the same place, but I'd still like to know why the theoretically more reliable approaches don't work. I believe the BaseStation program was written using Delphi, could it be that the dialogs are not to the Windows standard ? Now we come to the solution without using MouseClick... TJ123 wrote: All too often one is told to search the Help but that's not much use if one is unfamiliar with the terms and doesn't know what to look for. Help files often require considerable familiarity with the subject. I have been writing programs in Delphi 7 for 10 years and I still have trouble finding what I need in the help. I can see from the help on "Send" that Send("{a down}") ;Holds the A key down etc. I don't have to hold the key down when using the keyboard, nor do I need to use ALT: - "y" or Enter does just fine as the Yes button has focus by default. So no matter how many times I read the Help on Send I would never have realised that this might be relevant - however, the suggested: works like magic ! Though I have no idea why this downing and upping business should be needed when it wasn't needed for the NotePad example. Here is my final script. My plan changed slightly, I'll start it after shutting down the BaseStation program manually. Of course, it will take a couple of weeks to test fully to completion, but I've tried it with a 1 minute sleep rather than a 1 day sleep, and it works just fine. ; script to stop and restart BaseStation.exe every 24 hours ;Program BaseStation.exe will not be running when this script starts For $i = 1 to 15; number of days to run Run("C:\BaseStation\BaseStation.exe") Sleep(86400000) ; milliseconds in a day - exact time will drift a bit but that doesn't matter WinClose("BaseStation SBS1") WinWaitActive("Confirm", "") Send("{! down}") Send("y") Send("{! up}") ; BaseStation now takes a while to tidy up its sqlite database, save its data and close WinWaitClose ("BaseStation SBS1", "", 60) Next ; now return to normal operation in case I forget to restart manually Run("C:\BaseStation\BaseStation.exe") WinWaitActive("BaseStation SBS1") Sleep(10000) MsgBox(4160, "SBSrestart terminated.", "This script has restarted BaseStation " & String($i) & " times." , 0) So, many thanks again, I'd forgotten how useful AutoIt can be. There may be odd inconsistencies in the formatting above, for some reason the message posted itself before I'd finished, and when I tried to edit it everything went haywire ! Caravelle

It's been a long time since I last wrote an AutoIt, script, and I have even less hair and brain cells now. I simply need to automatically shut down and restart a data collection program once a day while I am away. This looks like it should be a no-brainer, there is even a simple example using Notepad to copy, and the NotePad example works on my Vista laptop. However, my test script fails miserably... Run("C:\BaseStation\BaseStation.exe") WinWaitActive("BaseStation SBS1") WinClose("BaseStation SBS1") WinWaitActive("Confirm", "Do you really want to shut BaseStation down?") Send("!Y") In the final script the first line will be transferred to the end, followed by a Sleep() for 24 hours, and the whole lot will be put in a loop to run as many times as the number of days I'm away. I start the script at midnight the day before I leave, and when I come back I should have a neat set of day-long data sets, ready to be analysed. So what happens ? BaseStation.exe opens Just fine (line 1). It starts the closedown procedure just fine (line 3). It opens a TMessageForm window with header "Confirm" (as, er, confirmed by Window Info, containing the exact text "Do you really want to shut BaseStation down?" and two buttons, Yes and No. However, whatever I try to send to the MessageBox, nothing happens, and the script doesn't terminate I've tried "Y", "y", "!Y", "!y" and "ENTER, all of which do the job from the keyboard. All I can see in the way of error reports is a line in the bottom pane of the Editor saying "C:\AutoIt3\SciTE\..\autoit3.exe" /ErrorStdOut "C:\Users\Public\AutoIt Scripts\SBSrestart.au3". I don't have a clue what that means apart from the fact that there is an error somewhere. The message appears before BaseStation.exe even opens. So, sorry to be a pain, but there has to be something obvious I'm missing. Many thanks to anyone who can tell me what it is. Caravelle

Ah. That might explain a lot. The script does seem to work properly up to the point where an IE.au3 UDF is called. I guess I can answer my own question about XP-compiled scripts running on Vista by trying something else that doesn't involve using IE.au3. Thanks Caravelle

Sorry, but can you give me a clue please where I find this setting? I couldn't find anything helpful in the MS help (nothing new there!). All I can find in the Internet settings is for disabling script debugging, and the settings are the same on both XP and Vista machines. Thanks Caravelle

Thank you, but I did not miss any code to show you. My question was a general one at this point: Only if the answer to that question is "no" do we need to start looking at code. If it is "yes" then I install AutoIt3 on the Vista machine and compile the script there, and then again only if it does not work do we look at the specific code. I find it much easier to resolve one issue at a time to avoid confusion Caravelle

I'm not sure if this is a scripting problem, a GUI problem, an IE.au3 problem, a compilation problem or what. My GUI-based script takes input, goes off to a website (which remains invisible), transfers the input into a search form, collects the results and shows them in my GUI. It's not quite finished yet, more error-checking needed, but it works - at least it works on the XP machine it was written and compiled on. But the compiled exe doesn't work on Vista. On Vista it opens the website visibly, doesn't enter anything in the search box and appears to hang. I have to use Task Manager, which says it is not responding, to close it. There are no error messages. Have I missed something obvious? Does a script need to be compiled on Vista to work on Vista? IE7 is the default browser on both machines. I can't find anything in the help that suggests this might be the case, and my Delphi XP programs run a treat on Vista but you never know. Thanks Caravelle

Thanks, but I can't agree with you there. $Count is between an end quote and a start quote , not the other way around. It's definitely outside quotes. Are you saying that the concatenation operator & and the items it concatenates don't have to be outside the quotation marks surrounding the string? Caravelle

I thought I had found the error, I was trying to concatenate a number into my string. However, it still does nothing when $Count is converted to a string.. For $Count = 1 to 6 ControlSend("", "", "[CLASS:Edit; INSTANCE:" & String($Count) & "]", "") Next Caravelle

Can anyone please tell me why this snippet of code does nothing? (no errors are reported). I am trying to send a blank to each of the 6 Input boxes in my AutoIt GUI application, in order to clear them. I know I could achieve this by GUICtrlSetData("name", "") for each instance but because this is something I shall need a lot in many proglets, I plan to turn it into a UDF which clears all the inputs and/or edit boxes in the current window without knowing in advance what their ControlIDs are. For $Count = 1 to 6 ControlSend("", "", "[CLASS:Edit; INSTANCE:" & $Count & "]", "") Next Thanks. Caravelle

Dale wrote: Thanks Dale. I was looking at the file "Examples.txt" that goes with IE.au3 in the "Ultimate AutoIt Scripts Collection" download. Good news. That's par for the course, then. But can you point to an example in the helpfile (you mean the AutoIt3 Help, I presume) which gives a clue about the way it does work? A lot of people would save a lot of time going down blind alleys if there was a commented example for, eg, posting a zipcode query at http://zip4.usps.com/zip4/welcome.jsp, and retrieving the result. And it might actually be a practically useful script. The main sites I'm interested are far more obscure and members-only so it wouldn't be a case of doing my work for me. Caravelle

Well, this newbie has made it past the second Tutorial, and already worked out how to write a GUI applet to get to a web-page, but got stuck at the point where I wanted to insert some text (a variable from an edit control in my GUI) into an input form. The Windows Info tool doesn't give any information I could understand about the browser window. The mouse coordinates it indicated didn't correspond to where the mouse cursor ended up when I positioned it at those coordinates. I counted the number of manual Tab presses needed to get from the home page to the input form (16) and sent 16 Tabs. Nope, all that did was somehow take me to a different part of the site. My blind friend in Sacramento who has to navigate by tabbing through every control, link, image, advertisement etc on a web page, waiting for the speech synthesiser to tell her what it is, just to get to the useful bit, has my every sympathy. I'm hoping to write a few useful scripts for her, to get her straight to what she needs, and indeed read and copy it into a more friendly form offline. Then I discovered IE.au3 and even though it's another of those cases where you can't learn it if you don't already know all those obscure IE-related terms the documentation is talking about, it looks fairly hopeful. So I tried the first example, copying and pasting the code below into SciTE and saving it. And it didn't work. The function _IEClickLinkByText is an unknown function name, it says. But I can see it in the IE.au3 file, which is in my autoit\include folder. This is typical of the basic problems that plague me all the time and doubtless is why I may sound just a little bit frustrated now and again. I suspect the other UDFs are equally unknown but as the applet stops at the first one, I can't tell. #cs This sample code will: 1) Create a new browser window 2) Navigate to http://www.autoitscript.com 3) click on the 'forum' link 4) click on the 'Search' link 5) get the object reference for the form named 'sForm' 6) get the object reference for the form field 'keywords' in the form 'sForm' 7) enter the value 'ReadyState' into the 'keywords' field 8) submit the form to return the search results #ce #include "C:\Program Files\AutoIt3\Include\IE.au3" ; I tried this as an alternative to the original #include <IE.au3> ; I also tried copying IE.au3 into the directory where the script is located $o_IE = _IECreate () _IENavigate ($o_IE, "http://autoitscript.com") _IEClickLinkByText ($o_IE, "forum") ; app stops here _IEClickLinkByText ($o_IE, "Search") $o_SearchForm = _IEFormGetObjByName ($o_IE, "sForm") $o_Keywords = _IEFormElementGetObjByName ($o_SearchForm, "keywords") _IEFormElementSetValue ($o_Keywords, "ReadyState") _IEFormSubmit ($o_SearchForm) So, can anyone kindly suggest why the function I can see with my own eyes in the right file in the right folder is deemed "unknown"? Second, is it in fact possible to use these UDFs to type text into a form control in an .asp page, send Enter and after a pause tab on to the controls where the results should come up, then copy the results back to the edit boxes in the AutoIt GUI applet? Or am I wasting my time trying to understand them? Be honest, please. If it's possible and there are examples that work, I should get there under my own steam. Thanks Caravelle

Puzzled again, but I'm spending far too much time on Forum messages and not enough time on getting started writing my scripts. so I'll leave it. Thanks for both your messages. Again I think it's all a matter of taking what the Tutorial actually says as Gospel and trying to draw conclusions from it - which is all a beginner can do. If I hadn't had the initial trouble, then I wouldn't have discovered that the text and the exclamation point were options for specific cases, and used in this example even though it isn't such a case. And which bit of text you choose is irrelevant so long as it's unique. Great, it's good to have options like this. But the tutorial could have been a bit more illuminating on the subject. Basically then, the answers to my whys are "because we chose to do it that way - we didn't have to and neither do you". No programming reason at all. Oh well, never mind. Thanks again Caravelle

JdeB wrote: I am afraid that the tutorial itself disagrees with you, and anyone reading it is told that the intent is something different. The tutorial follows the good practice of stating its purpose. It says: If what you say is correct then it would say: This is really nothing to get upset about. Other contributors seem to have regarded your earlier reply as dismissive and off-putting but I did not feel "chewed out". Merely puzzled It is always wise to assume a degree of mutual incomprehension when corresponding with someone whose first language is not the same as one's own. I am English but my own grandchildren are French: even though we all speak both French and English, we often fail to understand each other. I have the same trouble with my friends in the USA All that is happening here is that you were seeing the issue from a different perspective which is denied to anyone who just has the tutorial to rely on. Let us move on and forget this. In any case, as I said originally, I succeeded in making NotePad close automatically by using the code in the script example. But I still have questions which the tutorial does not answer. Here is the given script again: Run("notepad.exe") WinWaitActive("Untitled - Notepad") Send("This is some text.") WinClose("Untitled - Notepad") WinWaitActive("Notepad", "&Save") Send("!n") (1) No-one has addressed the issue of "!n" as opposed to "n" to trigger the negative button. I have spoken to a friend who has Vista and she confirms that NotePad in Vista does not require ALT+N either. The plain n key works just fine. So Vista, XP or whatever, why do you use "!n" ? Is it recommended practice to use the ALT key even if the plain key works? (2) Why "WinWaitActive("Notepad", "&Save")"? Why not: "WinWaitActive("Notepad", "&No")" ? Why not "WinWaitActive("Notepad", "No")" ? The example script Notepad1.au3 (which specifically states that it is for Win 9X/NT, by the way) says "WinWaitActive("Notepad", "No")" without the ampersand. And that works in XP too. And having checked the help on WinWaitActive, I discover that the second parameter is optional anyway! So Why not "WinWaitActive("Notepad") ?. It works. In order to understand what I am doing I need to know if it matters whether or not the exclamation marks and ampersands are included and if it matters which bit of Window text (if any) is pointed to by the WinWaitActive("Notepad", ...) statement. Only then can I start writing my own scripts with any confidence that they will do what I want. I know from Delphi programming that the details can make a huge difference. I will not take offence if someone points me to a part of the Help I have not discovered yet. Thank you in advance. Caravelle

Thanks for the quick responses. JdeB wrote: Do you mean that this version of the Help addresses only Vista, but the example scripts provided do not? In that case, is there an earlier version of the Help available which does address Windows XP? A person who has never used Vista simply does not know what the differences are likely to be, and is unlikely to know that there will be differences at this level. NotePad is NotePad is NotePad - except when someone tells you that a NotePad you have never seen is not NotePad. Yes I read the whole page. Yes, I followed the steps, but I did not know why the illustrations differed from what I had on my screen. Before retiring I spent many years writing instructions based on the law. The law changed frequently, so the instructions had to be rewritten, but people would still be dealing with cases under the old laws - it was possible for many different versions of the law to apply to the same case depending on how long it had taken to deal with. It was a key feature of the instructions that they should state clearly at the outset which set of laws they referred to - there could be serious consequences if the wrong law was applied. When the same situation needed different guidance because an older law applied to the case, the instructions would either explain the earlier guidance directly or refer to the relevant paragraph of the earlier instructions. This was especially necessary because new staff would not be aware of the old instructions otherwise. This is a long way of saying that the Tutorials should say that they are written for Vista, and when some code or an illustration ONLY applies to Vista there should be a warning and ideally alternative code/illustration or less ideally a reference to an older tutorial that works under earlier versions of Windows. I don't wish to suggest that the entire set of Help is not an impressive document - it is brilliant by comparison with the Help in countless other packages, even the big commercial ones from the likes of Corel. But a beginner's tutorial needs to be crystal clear because you cannot assume that the people reading it understand either the background or the context, and there is no teacher present who can be asked to explain something one does not understand fully. This is especially so when the subject is technical and requires a grasp of detail. I have several Delphi components which I am sure will do exactly what I want if only I could understand how to make them work, but what help is provided does not start at the beginning, rather it assumes familiarity with the very thing one is trying to learn. I have come across this problem so many times over the years. It can be very frustrating and discouraging. So thanks again for explaining - but if the Tutorial explained, you wouldn't have to. Maybe from this point on the Help is perfect Caravelle