rberq

Put the entire URL in T1 variable Variable Set Integer N1 to location of "ID=" in T1 Variable Modify Integer N1=N1+3 (to allow for the ID=) Variable Modify String T1 -- delete characters 1 through N1 At this point the first integer is at the beginning of string T1 because you deleted everything before it You know the number of digits in the integer (10), so Variable Modify String T1 -- copy 10 characters into T2 At this point you have isolated the first integer string into T2 Repeat above coding to isolate the second integer string into T3

I use a method somewhat like Paul's, which converts the standard 99 ME3 N and D variables to text strings, appends them comma-delimited into one T variable, and stores the composite T variable into a single environment variable. That's the "save variables" macro. The 99 T variables are saved each into its own environment variable -- just because I didn't want to worry about what delimiter could be used that would never be in any of the T variables. The "restore variables" macro does just the reverse, retrieving the contents of the environment variables and converting strings back to N and D variables. It is surprisingly fast. Actually I have several sets of these save/restore macros, using different environment variable names. That's so that different sets of application-specific macros can operate concurrently without tripping up one another. The only worry is that I might exceed the available storage for environment variables. The other disadvantage is that now, with ME Pro having arrays and user-created variable names, the save/restore macros would have to be modified every time I define a new variable. I do like the idea of passing initial variable values into macros via an INI or TXT file, and I can already think of several places I should have used that technique, had I been smart enough to invent it like you guys did.

Is it possible the COPY TO CLIPBOARD command is running before the web page has finished loading? Try throwing in three or four WAIT FOR WEB PAGE TO LOAD commands (wait indefinitely) after (or in place of) each of the WAIT FOR WINDOW TITLE commands. Each web page wait takes a minimum of about a second, but if IE goes to "not busy" several times in the course of completing the page load, you may need more than one wait. Don't use both a CLIPBOARD COPY and TEXT TYPE <CONTROL>c -- they both do the same thing. Try one or the other, but not both.

Thanks for the primer. I was familiar with INI files but just never noticed how to use them in SET and MODIFY variable commands. I have been so busy with ME I have never taken the time to go through every ME command variation, so I keep missing out on neat things like this.

Cory, you have mentioned INI files a few times, and I'm totally ignorant of them in regards to Macro Express. Does ME do something special with INI files? Or are you just saying you store information in files whose filetype is INI -- but could just as well be CFG or TXT or XYZ????

I didn't get a party either when I became Advanced. I don't know the criteria, but I suspect it's just based on number of postings, a recognition of persistence rather than expertise. So I haven't let it go to my head.

Well, now, not to quibble, but you didn't FIX it, you found a work-around. And if a macro NEEDS the variables from previous macros, adding a SAVE before your RESTORE will simply wipe them out because they are all empty at the beginning of the macro. Actually I don't care any more, either, as I have converted to stowing the values in environment variables. If I get too many large ones, I suppose I'll have to switch to storing in files due to limited memory. What other techniques do you guys use? Using files sounds like it would be slow.

If the file name now has an embedded space, I wonder if you have to enclose the whole thing in "quotes"

For debugging, temporarily put a Text Box Display command before your rename attempt, to show you the value of %T2% that is being used. Bracket the T2 value with special characters so you can see whether there are trailing blanks; for example in the body of the text box put >>>%T2%<<<.

I never have quite cared enough to figure out what the "Archive" attribute means. I don't believe it has anything to do with zipping, but I suppose it is possible that one or more zip programs might set the attribute. You could test and find out -- I still don't care enough.

WinZip has a command-line interface that you could use. I don't remember if it's a freebie to licensed WinZip users, or if you have to buy it. With ME, you could build the .bat file of WinZip commands, the use Launch Program to run the .bat file.

Well, it looks like you found where the slowdown occurs. I can't tell you why ME is so slow by comparison with a .bat file. If time is critical to you, you could use ME to build the .bat file, then use Launch Program to execute the .bat. That's a pragmatic solution, if not exactly an elegant one.

Create a .bat file to do the same renames, time it, and report back. That should tell us whether it is Macro Express that is slow to do renames, or Windows.

More great outside-the-box thinking, Cory!

Your problem is almost certainly in the clipboard use. To echo what Cory said, clipboard functions are notoriously unpredictable as to how long they will take. Especially Copy to Clipboard, and even commands like VARIABLE MODIFY STRING - SAVE TO CLIPBOARD. Timing is unpredictable from one PC to the next, and from minute to minute on the same PC. Search the ME3 and MEP forums for "clipboard" and you will see some tricks that others have found useful.

I have frequently seen crashes of ME3 at the point where I save a macro I have been editing; also when clearing the recycle bin. Usually the ME message says something about the .mex file being corrupted, or not a valid macro file. Crashes seem to be directly related to scheduled macros that may be running (or trying to run) at the time the .mex file is to be updated. My crashes are not as bad as your crashes; all I have to do is restart ME, and always I find the edited macro was saved successfully prior to the crash. As long as the scheduled macros are disabled, no problem. I realize ME3 is not MEP, but it's something for you to consider....

Ouch! I really really need to go to MEP, for its ability to lock mouse and keyboard. But I use Save All and Restore All many many times across several dozen macros, so the excessive time will be a problem. I have written logic for ME3 to stash Tx, Dx, and Nx values into environment variables, and retrieve them again, and it's very fast but it's not dynamic -- that is, it won't automatically pick up any new variables that I might define in MEP. Ideas, anyone?

Can you point me to the discussion of which you speak? I have a slew of macros which run based on window titles. They must pass quite a number of variables among themselves. Since they are not called by one another, they can not use global variables (which, as you pointed out, are not really global). Short of storing the data in environment variables or in the registry, I don't know an alternative to the Save All and Restore All method. I'm all ears, though, if someone can tell me a better technique.

Thanks from another Bob for your writeup, Cory. But, another question: In ME3 the standard variables could, in effect, be made global by using SAVE ALL VARIABLES just before exiting each macro, and RESTORE ALL VARIABLES at the beginning of each macro. Does the same hold true for ME Pro?

Bummer. Doesn't work for me! I wonder what's different between your machine and mine. Mine is XP Pro Service Pack 2.

Go to the Properties for the macro. Checkmark the Schedule box. Click the Set Schedule button. Within the Set Schedule panel, select Other at the top, checkmark Play Macro Indefinitely, and set the frequency near the bottom of the panel. The macro will then run every x seconds, whatever you set it for.

This code snippet will find the current color at a spot on the window, x-coordinate 120, y-coordinate 84, then it will idle in a REPEAT loop until that color changes to something else. I put a quarter-second delay inside the loop just on principle -- in some computer languages it would keep the loop from eating up all available processor time. With ME it probably doesn't make much difference. If you know the default color for sure, then you can just load it into N93 and N94 before starting the loop, rather than getting it from the screen. Bear in mind that the default may change with 16-bit vs. 32-bit color, or if the email site changes its display a little. // .... find current pixel color where the change will occur Variable Set Integer %N91% to 120 Variable Set Integer %N92% to 84 Get Pixel: Window Coords: %N91%,%N92% into %N93% Get Pixel: Window Coords: %N91%,%N92% into %N94% // .... wait for selected pixel to change as a result of email Repeat Until %N93% <> %N94% Get Pixel: Window Coords: %N91%,%N92% into %N94% Delay 250 Milliseconds Repeat End

Sorry, I think I should have explained in more detail. I wanted to test whether one macro could block input (via autoit), and a second macro could unblock it. Both of the macros consist of a single line, launching an au3 script. Macro 1 launches the blocking au3 script and then the macro ends immediately. The 30-second delay is in the au3 script, not in the macro. Macro 2 launches the unblocking au3 script and then the macro ends immediately (and runs again and again, every 3 seconds). I can see from the ME log file that Macro 1 runs when I start it. I can see from the ME log file that Macro 2 runs multiple times before, during, and after the 30 seconds that the blocking au3 script is running. But the input block does not clear until the original blocking script finishes. Therefore, it seems that when one au3 script has blocked input, another au3 script can not unblock it; only the original au3 script can release its own block. Is this your understanding of how AutoIt works?

I'm working with AutoIt for the first time ever, and have a problem which is no doubt self-inflicted. ME macro 1 launches autoit3 with parameters to run an au3 script which is simply BlockInput(1) Sleep(30000) BlockInput(0) This does as I expected, locks the keyboard and mouse for 30 seconds, then releases them. ME macro 2 launches an au3 script which is BlockInput(0) I scheduled macro 2 to run every three seconds. What I expected to see was, when I run macro 1, the mouse and keyboard would stay locked for only a few seconds. But the second macro and script has no effect -- the input stays locked for the full 30 seconds. Howcum? Microsoft documentation for BlockInput mentions that a block must be cleared by the same thread that established the block. Is that what the problem is -- the second macro and script are a different thread? What can be done about it?

I'm afraid I won't be much help. I know nothing of Delphi. I tried to do it today as my first-ever project with AutoIt. It should be a one-line AutoIt script: BlockInput(1) or BlockInput(0) to lock / unlock both the mouse and keyboard. But it's not working for me. I must be doing something wrong. I suppose I should just give in and install ME Pro, since we just upped our licenses to 100. But we're in the middle of rolling out a couple projects developed with ME3, and that's not a good time to rock the boat.