acantor

Macro Express Pro supports error trapping, including the ability to perform an action when a command times out. It would be easier to accomplish what you want to do with MEP.

Variable Set Integer %MouseX%: Set to the Mouse X Coordinate Variable Set Integer %MouseY%: Set to the Mouse Y Coordinate <Do something> Mouse Move: %MouseX%, %MouseY% Relative to Screen

When I use Macro Express, I use the Mouse Locator tool. When I use AutoHotkey, I use its Spy feature.

I wonder whether the slow-to-execute problem could be related, in part, to processor speed and RAM. I experience it less often on my "high end" home computer than on my slightly underpowered work computer. It would seem window activation is not quite right yet. (Did it work better in ME3?)

I have a macro that is designed to trigger every time an Internet Explorer window that contains certain text in the title bar opens. When I change the activation to "Window gains focus" instead of "Window is opened," the script seems to work reliably. When I switch to "Window is opened, "however, one of three things happen: 1. Nothing. The window is not recognized, even though the window title definitely contains the text, and no other window has this text in its title. 2. Everything. The window is recognized, and the script runs. (But not every time!) 3. Everything, but the process takes too long. The macro does not activate until the window has been open about ten seconds. I have tried many variations, but I am running out of ideas. For example, activate when a process starts running works, but it takes too long to activate. Any ideas on how this force this script to run instantly as the result of the creation of a window? (In this situation, "Window gains focus" is OK for testing, but not for real life.)

Double check the macros, especially the activation and scope. Try changing the prefix to something simple, e.g., "Q" or "5," and retest. Try changing the prefix to a suffix, and retest.

I thought you might like it. The one-liner is a perfectly good approach, but I can imagine it failing under certain conditions. The control-based approach, on the other hand, inches us closer to a programmatic way to script reliable macros.

I think you may be on the wrong screen. 1. Create a new macro -- let's call it A. 2. Go back to Macro Explorer, and create a second new macro. Let's call it B. 3. Activate the "Get Control" utility in B to capture the "Macro Nickname" field on the "Create New Macro" screen for A. Alternatively, this script works nicely if the script consists only of this line: Text Type (Simulate Keystrokes): <TAB><TAB><TAB> Which automatically tabs to the Macro Nickname field when the window opens.

I just tried again. Now I find that I only have to press Tab once. Then I can press Alt + whatever. Here is a script that automatically places the focus ib the Nickname field when the "Create New Macro" window opens. Get Control: (MACEDIT.EXE) Using z-order -> %NicknameField% Set Focus to %NicknameField% Set the activation to Window Title: "Create New Macro" (exact match) when Window is opened. Set the Scope to Global.

It's doable, although not obvious... 1. Press Tab seven times. 2. Press Alt + underlined letter. Unfortunately, once the radio buttons have focus, the up and down arrow keys do not work, which is the expected behaviour.

The size of the macro file may affect performance? I just deleted 600 macros from my .mex file, emptied the recycle bin, and used "Pack" from the "Tools" menu. I will report back on changes in performance, if any. Size before: 2846 kb Size after: 895 kb

Hi Terry, I have begun to experience something similar recently. One of my computers has an Intel Core 2 duo CPU, 3 GB RAM and runs Windows XP. I am wondering what would happen if I had a faster machine, but there is no way for me to know right now... Most of my Macro Express scripts for this machine are fine, except for those that run in Internet Explorer. Many scripts take five or more seconds from the time I activate them until they begin to do their thing. Furthermore, many commands that I have always placed one after another require timed delays between them. For example, I have been forced to add delays after "Wait For Window Title" commands. I have never needed to do this before. The problematic scripts are for a web-based application that runs exclusively in IE. My guess for the reason is that the HTML and/or JavaScript that underlie the application are getting in the way of Macro Express Pro. I have managed to get the scripts to work reliably, and have even found ways to speed things up; but to do so, I have had to sacrifice portability. Normally, I resist developing scripts that rely on mouse positioning. With this application, however, there is a significant speed penalty when I use my normal techniques instead of moving and clicking the mouse pointer. When I upgrade the computer I will likely need to rewrite everything.

They monitor this forum. The best approach is to submit bug reports and feature requests. Several bugs I have spotted and reported were fixed in subsequent releases, so the approach can work!

I have simplified the display of the macro scripts to enhance legibility, including removing the icons and rearranging the columns so the ones I need to see most often are on the left. But you are right, it would be very nice to be able to increase the font size... It would also be nice to give focus to a command by typing its name, rather than entering a search mode, holding down arrow keys, or using the mouse. In Version 3.x, one could, in the blink of an eye, navigate to a command nicknamed "XXX" in a list of 500 commands by typing "xxx." This doesn't work in Pro; instead, you have to press Ctrl+F, wait for the window to appear, type xxx, press Enter, and then press Esc. Maybe I should file a feature request...

Cory has said it well... timing is often a challenge when developing macros. Even with an elegant solution, such as waiting for a window title, control, mouse cursor shape, or whatever, sometimes timed delays become necessary. While fine-tuning a script, I get rid of timed delays, but inevitably, some are needed. I try to balance reliability, speed, portability, and robustness. My starting assumption is that no macro is 100% reliable. I am willing to give up a smidgeon of reliability to gain a little speed. At least for my own use. One of my more complex scripts fails once every 15 or 20 runs. I can get it to fail once every 25 runs, but it takes twice as long to execute. There is a whole other art to getting scripts to fail gracefully...

Not everybody needs the Pro version. Much depends on the kinds of scripts one develops, and how much time one spends scripting. I find the Pro version preferable for complex projects, but in a pinch, ME is perfectly serviceable. Only occasionally do I need an MEP feature. For a novice, Macro Express is excellent. In fact, it's the best introduction that I know of. (I have taught many introductory courses on macro scripting, and I have always used ME. The Pro version would be overkill.)

An OCR scan, if it exists, would be ideal. But there may be other ways to detect the numbers. What is it exactly that contains the image of the number? Is it a control in a Windows application? Is it an image on a Web page? If the former, MEP may be able to gather information about the control. If the latter, MEP may be able to suss out its properties, which might include clues about, or reveal the content: <img src="../images/3.jpg" alt="Glowing Numeral 3" /> To expand on Corey's explanation: Pixel sniffing routines (to detect patterns of colours) can be made to work reliably. But these projects are not for the faint of heart. The projects can eat a lot of time to figure out appropriate scripting approaches. One of my MEP scripts performs over 1000 steps each time it runs to find colours and keep track of the patterns. The macro executes almost instantaneously, as it uses variables to track position rather than mouse cursor movements. Rather than this: Get Pixel Color from Beneath the Mouse into %PixelColour% It uses this: Get Pixel Color at (%x%, %y%) Relative to Current Window into %PixelColour% For complex pixel sniffing problems, I find the second approach runs significantly faster than the first.

I have scripted dozens of MEP macros that allow me to control a complex web-based application by keyboard and voice. All of my scripts work by manipulating the User Interface: click here, tab there, search for a pixel colour, monitor the shape of the mouse cursor, etc. The macros are surprisingly reliable, but as a whole, I find the system ungainly. Some of these macros perform thousands of steps to identify and navigate to a hypertext link; others only work if the object I am trying to act upon is visible. I am tired of these limitations! I want to understand how to approach these tasks programmatically, but I cannot quite figure it out. How can I reliably move focus to a certain edit field; select an item from a drop down list; click on a "Save" or "Close" button; check or uncheck a particular checkbox; and activate a link... without dozens (or thousands) of lines of code that may or may not work if I switch screen resolutions. "External Script" commands look promising, but I cannot figure out how to use them to perform even simple tasks. I would appreciate if contributors to this forum would post code samples that illustrate how they use "External Script" commands to check a checkbox, focus a particular field, etc. in applications that run in a web browser. I have been on this forum for years and have greatly increased my ability to work with MEP. My sense is that many experienced MEP scripters are "stuck" exactly where I am. I am ready to move on to the next level, but need a little help!

The "Variable Set Handle" command looks like a promising way to identify windows, but I cannot figure out what to do with the variable after it has been captured. Can anybody give an example? In other words, once I have done this... Variable Set Handle %HandleTest% from a window with the title, "- Microsoft Word" ... what MEP commands can I use to act upon that window?

There is a title when I run Windows Explorer in Windows 7. Maybe some setting???

How about wrapping Repeat commands around the main part of your script? Repeat Start (Repeat 730 times) Main code goes here End Repeat

1. Is the scope incorrectly set? If it's not already "Global," try changing it to that, or making it Window or Program specific. 2. Check that no other macro has the same activation as your login macro. You may have a conflict. 3. Change the way you send text to the PDF. Try typing out the text and pasting it. Try sending one character at a time. Capture the control, and then try sending the text directly to the control. 4. Try moving the mouse cursor to the insertion point, clicking or double clicking, and then typing or pasting the login info. 5. Try emptying the clipboard, assigning the password to the clipboard, and then pasting instead of typing it.

If you can move the mouse cursor over the information you want to capture, this code copies the information to a text variable, which can then be parsed. Capture Control from Beneath the Mouse into %Control% Get Control Text from %Control% into %Text% A somewhat reliable hack -- is that enough of a contradiction? -- to move the cursor is to find out where the information is located in proportion to the window's width and height, e.g., as measured from the top left corner, 30% of the window's height, 10% of its width. The information you want to capture is in different places on the propery screen in different versions of Windows. So forget about portability!

I still use this technique occasionally, and I can usually get it to work. Usually the script looks something like this: [ESC][ESC] // Cancel menu if accidentally open {CONTROL}f // Find... <word to find> {Enter} // Initiate search [ESC] // Cancel search Delay 200 ms // Wait for window to regain focus after search bar loses focus {Tab}

Terry, Have you tried capturing controls as a way to distinguish the different parts of the user interface? Then use "click on control" or "set focus on control" to activate the part of the UI. The technique works beautifully in some applications, but not at all in others.