Pallindrome

I found in a quick search - might be helpful to you

Firstly, I'm assuming that this is a DOS window under Windows as opposed to a full DOS session initiated from a boot disk - there is a very important difference between the two! Part of the problem is that any call to a script, compiled or otherwise, will initiate a new instance of that script rather than using an already running instance. This means that creating redirecting scripts for "set" and echo" to point to a single master script "newcmd" and passing the parameters will still create a new instance of the script, so any memory variables used by previous (or still running) instances will be inaccessible. For workarounds, you could use the shell variable structure for storage of a limited amount of data, use a file storage (flat file, INI or XML) or even write the data to the registry for storage. It may also be possible to get a hook in to an existing running script by calling it via it's PID, but this may mean writing some extensions for AutoIt, similar to calling functions and procedures stored in an external .dll (which may not be a bad thing, but it would mean some pretty heavy development work!) The main method of attack so far is to get DOS to run AutoIt scripts from within its shell and maintain memory continuity between them. Lets put AutoIt outside the DOS box instead! Use the AutoIt script as the shell to execute the commands, and call CMD /c to execute those commands that aren't programmed into the main script! The result is that all the 'set' and 'echo' commands are now interpreted by the main AutoIt script, which remains in memory so all variables are available. Any commands not understood by the script can be passed off to an instance of cmd.exe, which returns control to the main script upon termination. Hopefully that will spark your imagination

Odd that it truncated the first parameter for the error message, returning only the ".vbs" part of it! I'd be tempted to write the output to a text file and examine it carefully there to determine why it is breaking at that point. Alternatively, rename that text file to a *.cmd file and try to execute that from a command shell to see if there are any error messages returned from wscript.exe that may give a clue as to the cause of the problem - some of those messages are returned using printf instead of standardIO and so the error handler doesn't see them! Just a thought!

Aha! So that's what controlclick is for!! I was wondering about it, but it didn't make sense in the short example I saw. That clears up my problem and gives me a whole new chunk of stuff to look through, thanks for the prompt reply!

Hi! I used Autoit many years ago for extensive testing of software and using some very large, involved and looping scripts. A friend of mine is having difficulty with a program that I thought Auto-it could help with, and made great progress with it but I've found I'm suddenly stuck on one single point, so I hope someone can help out! The sticking point is that the target window that has no keyboard shortcuts (take a look at GUI - Message Loop.au3 in the tutorial for an example of this). The button I need to hit is at the bottom of the second tab, and under a dynamically resizing field. I can't guarantee which tab will be open when I need it, nor which field will have focus on that tab, and obviously the position of the button will change depending on the size of the field above it. Is there a better way of getting at this button without taking a machine gun/fire hose approach and clicking at 5 pixel intervals from the bottom margin upwards in hopes of hitting it? Suggestions are welcome, thanks!!