rberq

The file-processing does happen in the background, without any window involvement, so you should be OK there. John told you how to write text files. Look at commands "Ascii File Begin / End Process" and "Text File Begin / End Process" for reading the files back in after they are written. As John mentioned, using INI files may be a better approach -- writing and reading is simpler, but the quantity of data you can store in one entry of an INI file is severely limited. You can also store strings in environment variables, which can be created on the fly -- see Variable Modify String and Variable Set String commands. The size of a string stored in an environment variable is also limited, but not as badly as INI values -- env variables follow Windows rules, I believe.

Yes! I have seen the same thing, but I thought it was unique to the weird application I was working with. The other issue I ran into was, on an extra-fast computer, by the time Windows (or IE?) changed the mouse pointer shape, the pointer had zipped past the target and the click fell on dead space. Had to set Mouse Speed to a few milliseconds to slow it down a bit.

If you are desperate enough, you could try opening the .mex file in a text editor, copy to clipboard what you think is your macro, create a new .mex, open that with the text editor, and paste in what you copied. Then try opening the new .mex with ME and see what you have. It's (barely) possible that you will come up with enough of your original to be useful. Or open a new macro in a new .mex with the direct editor and paste in what you copied, then switch to the script editor and see what is there. Probably a very low chance of success, but what do you have to lose?

Do you know, in one dimension, where the button is? Here's a method I have used a number of times: Let's say you know the button is at coordinates 123,xxx -- that is you know its horizontal displacement but not its vertical displacement. You move the mouse to something like 123,100, then in a REPEAT loop you increment (or decrement) the y-coordinate a few pixels at a time to move the mouse down (or up) the screen. At each mouse step you do IF MOUSE CURSOR = INTERNET NAVIGATE to see if the cursor has changed to the hand with finger ready to click, meaning the mouse is now on the button. You can search right or left, up or down, or scan a rectangular area depending on how you increment or decrement the coordinates. The biggest problem with this technique is, there may be other objects on the page that will also turn the mouse cursor into the NAVIGATE format. If you run into one of those before you find the button, then you are out of luck, unless you get REALLY fancy and calculate the size of the found object by moving the mouse up-down-left-right, or if you can rely on a color or something else to see if you have the right object.

It's not that easy. When a macro starts to run, all variables are cleared. To carry over a value you have to store the variable somewhere that will survive restarts of Macro Express and reboots of Windows. The most straightforward is probably an INI file. Build the INI file manually with a text editor. Then each time the macro runs Variable Set String [from INI file] Variable Modify String [convert to integer] Variable Modify Integer [increment] Variable Modify Integer [convert to string] Variable Modify String [save to INI file] You could store the string in the Windows registry. My preference (prejudice?) is to stay away from the registry. P.S. I just noticed you said you want to retain the count "during the session". In that case, you can store the string in an environment variable. The environment variable can be created on the fly with whatever name you choose to give it.

Very clever solution to an old problem. You should submit that as Insight's macro of the month and get a tee shirt or whatever.

I hadn't anticipated that issue. Thanks for the warning. My first idea, like yours, was an always-open mex file containing the common macros. I don't quite follow your explanation of why you can't do that. The problem only happens when you have more than one macro file open, but you normally have only one macro file open, so why is it a problem? You could create a macro that disables the common macros, and another that enables them. Then run the disable just before you close a mex, and run the enable just after opening another mex. It would be an effort to remember to do it, unless you can come up with a way to do it automatically.

Now that you have captured the macro, open it with the script editor (not the direct editor) and remove whatever mouse commands are positioning you to the wrong place. Once you are familiar with the script editor, you probably won't do much capturing of macros. It's often cleaner just to create a macro from scratch with the editor. For what you are trying to do right now, your whole macro will probably consist of a single line: TEXT TYPE [John Doe]

If I understand you correctly, Macro A is running, and you want Macro B to stop A from running. The Macro Stop command ends the macro in which the command is coded. In other words, Macro A can end itself with the Macro Stop command, but B can't stop A. In B, try using the Macro Disable command to disable A. I think that will stop A in mid-stream if A is running. It will also keep A from running again, until you issue a Macro Enable.

fori?

You CAN put the modified variable into the clipboard: VARIABLE MODIFY STRING/SAVE TO CLIPBOARD (it's on the second tab). But I have had little success with pasting from the clipboard, regardless whether I use the CLIPBOARD PASTE command (which says it issues Ctrl-v), or the clipboard-paste option of the TEXT TYPE command, or by directly typing Ctrl-v. It works sometimes in some applications on some PCs, but not reliably everywhere.

I think the Preferences for keystrokes is 300 microseconds, not milliseconds. That's not much time, but I think you can leave it at the default if you set Keystroke Speed in your macros. I have had to set Keystroke Speed AND Mouse Speed in many macros -- 30ms seems to work pretty well, though some applications are happy with much lower values. Like you, I have found that Wait for Text Playback makes the macros more reliable, though it is kind of slow! Wait Text Playback will not always compensate for a too-fast Keystroke Speed. If you are typing a long string of data, and keystrokes are delivered very fast by ME, then the Windows or application keyboard buffer can be overflowed because characters are coming in faster than Windows can handle them.

The check is in the mail. Honest ....

You win, Paul. I like yours better.

FWIW, I always use the sequence <CTRLD>u<CTRLU> instead of <CONTROL>u. In other words, separate operations for pressing down the Control key and for releasing it. Either way is supposed to work, but I have found the separate operations to be more reliable on some PCs. If you don't have Keystroke Speed set, try setting it to 30ms or thereabouts before typing the Control-u sequence. You might try a brief pause after typing Control-u to give the application time to digest it. Make sure the window is ready to accept keystrokes. For example, if you ACTIVATE WINDOW and immediately start typing, you may be outrunning the machine. Try a half-second delay prior to typing.

Move your string to another text variable (T99, say) so the original won't be destroyed by the following. Then VARIABLE SET INTEGER N99 from position of text (space) in T99. If N99 is zero there are no spaces at all in T99, so you are done. If N99 is greater than zero, add 1 to counter. VARIABLE MODIFY STRING replace substring " " with "x" in T99 (choose the option to replace just one instance, not all instances). At this point you have counted the first space (if there is one), and then replaced it with the letter "x". Now repeat the above until N99 is zero (all spaces have been counted and replaced by "x"). Whatever is in your counter is the number of blanks that were in the original string.

<IFOTH:04:2:lotusnotes><ACTIVATE2:lotusnotes><ENDIF> If Window Title "lotusnotes" is running Activate Window: "lotusnotes" End If On the IF command, choose the option Partial Match for the window title, not Exact Match. The Activate Window command always uses Partial Match.

Don't schedule the "working" macros. Write a "driver" macro that is scheduled to run at 7 AM, and all it does is runs the other macros in the desired sequence.

Tried adjusting Text Type Delay as high as 100,000 and it still was choppy. The macros already had Keystroke Speed of 30ms. But the application is working OK now, I just added Text Type <TAB> to tab out of the dropdown fields and that closes the dropdown list.

I have macros that identify windows by checking color "maps" with a few dozen pixel locations in each map. Like you, I also have seen that pixel locations can change slightly -- even within the same PC from one day to the next! -- so I am careful to map to the middle of fields, and don't check too close to the edges. Also, color value changes on a machine running 16-bit vs. 32-bit color, so I have two sets of color maps. But I have not seen any problems from machine to machine, other than those two differences. The macros run on dozens of PCs of different varieties. P.S. (Oh, yes. Pixel location may change, depending on the application, if you change screen resolution. For some applications it matters, for some it doesn't.)

Most entries to form fields are like this: Text Type (Simulate Keystrokes) <TAB> Wait for Text Playback Text Type (Simulate Keystrokes) %T[x]% Wait for Text Playback What I see on the screen is that ME Pro's "Text Type" is very choppy. If for example variable T[x] contains thirty characters, five or six characters will be typed, then there is a visible delay, then one or a few more characters, another delay, then a few more, and so on. I think this explains the dropdown lists -- where ME3 zipped through typing the whole field, MEP may initially type one or two characters, then delay, and the dropdown opens during the delay. So that explains the dropdowns, but what explains the choppiness? Testing so far shows choppy typing into Citrix windows. When typing into an IE7 page, typing is steady with no choppiness. This is on a comparatively slow PC. Incidentally, the Wait for Text Playback seems to be much faster with MEP (either that or the wait is being ignored and I just don't know it yet).

Thanks for the tip, John. I'm going through the same thing now -- multiple iterations of importing several dozen ME3 macros to MEP, then using a macro to apply a set of edits to each of the imports. Your method will be a time saver.

Confirmed on my PC. Not fixed in 4.1.5.1. Doesn't seem to matter what macro you are editing, closing the editor ends one or two running macros. Probably ends 3 or 4 or 5 or 99 -- I just didn't test above 2.

I like a variant on your job file drop. But it could be a single file, where each line in the file represents a job. Job (macro?) name would be one field of each record. Include a position in each record of the file for a status code: e.g. new, in-progress, complete. You could easily enqueue on the job (macro) name if you need to prevent the same job from running more than once simultaneously. Add date and timestamps for creation, job-start, job-end, etc. to whatever degree is useful. Pass parameters from the initiator to the macro if necessary. You can be as simple or as fancy as you want in the design. You will probably wind up with a set of common macros that will check and post conditions to the job file, and either call or be called by the macros that perform the business functions. In other words, pretty much a standard interface or queuing system, where one or more systems put items on a queue, and one or more other systems dispose of the items. A single job file, on a network share available to "everybody" is simple as long as the loose security is not too much of an issue.

Had to be a bug. It was inconceivable to me that you and I could both be that dumb. If it affects ONLY release 4.1.3.1 that could explain why others haven't seen it. Your average non-professional user probably does not get into arrays. It's scary, though, that this kind of bug would crop up in a maintenance release. I am testing dozens of macros in applications that register hospital patients, to convert the users over to ME Pro. It does nothing good for my credibility if we are bringing patients into the Emergency Room and the process goes to hell in a handbasket due to a silly ME bug.