rberq

I followed your explanation, but what about if I do not know the number of digits in the first integer , in the example it is 10 but it can be between 4 and 13 same for the second integer of witch it should be easier to get since no character come after the digits.

Sorry, I thought you said the number of digits would always be the same.

Once the string of digits is at the beginning of the T1 variable,

Variable Modify String T1 copy about 50 characters to T2 -- copy more than the largest number of digits you expect.

Then write a repeat loop to step through the T2 characters one at a time checking whether they are numeric or not. Keep a count of how many characters are checked, in another Nx variable. When you finally get to a non-numeric, delete that and all subsequent characters from T2. What you are left with in T2 is just the numeric digits.

Repeat the above to isolate the second string of digits into T3. It's a good idea, before starting this second process, to append a space to the T1 variable, so that you will be sure of finding a non-numeric (the space) before you come to the end of the T1 variable (in case the digits are the last thing in the URL).

There are other ways of extracting the digits, one at a time, into T2 and T3; but the above should work. There may be a simpler method than stepping through the digits one at a time, but I don't know what it is.

I need to extract some ID # and sub ID from an URL string ex:

 

http://yourid.xyz.com/index.cfm?fuseaction...esubID=18974678

(Click on the URL to see it in full)

 

So I want to get 4317378244 and 18974678 in two separate variables knowing the length of text may vary with the #number of digits from the integer ID and the alphabetical part stay the same

I am not sure how to achieve this .

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.

I actually fixed it by... saving variables before restoring them. Most macros already end with a save so it is just a redundant command. And feel free to report this bug. I don't care to look into it now that I have things working... relatively!

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....

Having said all that, the current release of MEP has a problem where the Variable Restore All command is incredibly slow, taking several seconds instead of the expected fraction of a second.

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?

Avoid Save All Variables.

..........................................

We had a discussion in here recently on that topic and the upshot is that you should generally avoid Save All Variables. Global variables and other methods are far better and there are some problems with it. In our discussion several arguments were offered but IMHO there were only a few esoteric cases where it was useful in MEP. As I see it the command is only present for reverse compatibility.

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?