rberq

Another idea: Schedule a macro to run once every second, and all it does is Copy to Clipboard. If you have highlighted something, it should get copied to the clipboard almost immediately. If nothing on the screen is highlighted, then clipboard contents will not change. If you don't want the auto-copy macro to run all the time, then write a second keystroke-activated macro to toggle it on and off (i.e. enabled and disabled).

Copy to clipboard, then Variable Set String [from clipboard]. Once you have saved the clipboard contents in a string variable, the clipboard is no longer involved. You can type out the string with ME, or do whatever else you want with it. I don't think there's any way to copy highlighted text directly to a string variable without going via the clipboard. Nor do I know any way that your text editor can copy from ME memory using a variable name. What text editor? Where CAN your text editor copy from?

Inside your Repeat loop is the place to increment the x-coordinate, though as Terry points out, the increment is not being done (N1 = N1 + 1). You can enclose this loop in another Repeat loop where you increment the y-coordinate (and reset x to the original value) after each set of 759 "horizontal" checks. If you don't explicitly want to watch the mouse move, the macro will run much faster if you check pixel color "at x/y coordinates" rather than "under mouse". Move the mouse only when you need it at a specific location in order to click. It is handy when debugging to move the mouse to each pixel-check position, so you get a visual of what the macro is doing. But then deactivate the mouse-move instruction or remove it once all is working right.

I don't understand. If I want to quote part of a post, I use the Reply button with the quotation marks, then I edit out the text I don't want within the quote. If I just want to add to the thread, I click the Fast Reply button. I still haven't figured out a use for the +Quote button. Edit: I just read your other post. Makes sense now. Except I still don't know what the +Quote button is for.

Agreed, with small sets and if both are sorted, the "simple" method is probably as fast, though once you start keeping track of start points it's only marginally simpler. What you are calling a shuffle sort I call a bubble sort -- yes I have written them. I also gave up on other sort methods because the bubble sort was "good enough". Also have written binary searches in IBM Assembler and COBOL languages, but not in ME. Later COBOL compilers were nice because they added a variant of the SEARCH verb that automatically searched binarily (new word?) rather than sequentially. Working with random check numbers flying through a check sorter at 20 checks per second, the binary search was the only practical lookup method fast enough to route the checks to the right pocket.

Now, this is going to be fun for you to write if you haven't already done so. You have described perfectly how to build a sorted array. But to scan the array you could write a binary search. That is, you first take the number of elements in the array and divide by 2 to find the midpoint. Say the sorted array contains 96000 entries, and you want to find out if the number 1234567 is one of them. You first compare 1234567 to position 48000 of the array. If 1234567 is greater than the value in position 48000, you set 48000 as the new low point. Find the midpoint between 48000 and 96000, which is 72000. Compare 1234567 to the value in position 72000. If 1234567 is lower than that value, then you have narrowed your search to the section of the array between 48000 and 72000; if 1234567 is higher than that value, then you have narrowed your search to between 72000 and 96000. Continue until done. In other words, you have a simple loop that, in each pass through the loop, divides the portion of the array to be searched in half. Because you are working a geometric progression, in effect, even a huge sorted array can be searched extremely fast. What is 2 to the 20th power? Over a million, I think. So with a binary search you can scan a sorted array of a million items in about 20 passes through your little-bitty loop. It's almost instantaneous from a computer point of view. Only when you have narrowed the array down to less than, say, 4 or 8 items, do you revert to a sequential scan of those remaining few items. An array of a billion entries could be searched with only an additional 10 passes through the loop, that is, 30 passes in all. An array of a trillion entries, 40 passes total. I'll bet you can have the ME code written in an hour.

It is as if ME sees that the window title has focus, queues the macro to run, activates the window, and begins running the macro. Between the queuing and the activation, the window has lost focus, but ME gives it focus again, which screws up the application. I will submit a support question to ISS to see if I can get clarification.

"AbcD" instead of "ABCD" involves the Shift key, where you are getting lower case and should be getting upper. "920" instead of (2) is the same thing, since the left and right parentheses are on the 9 and 0 keys. Oddly, I have seen this problem when allowing ME to use the high-speed timer. It went away when I unchecked the high-speed timer box. I also was able to resolve it by doing the following: Instead of instruction (for example) Text Type %T15% use three commands to paste via the clipboard Variable Modify String T15 Save to Clipboard Text Type <CTRLD>v<CTRLU> Wait for Text Playback

Here's partial confirmation: In ME3 I have found it logs the start of the macro reliably, but logging the stop is iffy, sometimes does, sometimes doesn't.

I haven't done it, but you might try: -- click the mouse within the dialog box -- CTRL-a to highlight all text -- CTRL-c to copy to clipboard

This isn't what you want to hear, but: With ME3 you have a simple macro that does the job in a very respectable length of time. With MEP you are considering complex pre-processing of your multi-megabyte text file, to get around a problem in MEP that ISS will probably resolve in short order. Why not just wait for that fix? If you must pre-process, MEP is probably NOT the appropriate tool with which to do it. It likely could be done quicker and far easier on the system that produces the report in the first place; or in a good text editor that can sort the lines and then delete huge blocks of them at one fell swoop. But since we are trying things (which I admit is great fun), I notice that your original ME3 macro loads the huge text file into a standard ME variable (T11, as I recall). The MEP macro loads it into a custom-named variable. How about you use MEP, but revert to loading it into a standard Txx variable and see if that makes a difference? (If MEP doesn't have the "standard" variables any more, then ignore my suggestion -- I don't have MEP yet so I'm just guessing.)

I have a macro whose scope is global. It is activated by window title XXX. It simply loops, recording the current time, as long as window XXX is on top. Variable Set String %T89% "0" Repeat Until %T89% = "1" [get current time and record in environment variable] If Not Window Title "XXX" on top Variable Set String %T89% "1" End If Delay 100 Milliseconds Repeat End // Variable Save All Variables // Macro Stop Window XXX contains a number of drop-down lists. When the user opens a list, (1) the list becomes the on-top window as far as ME is concerned, and the macro recognizes that and exits (2) the user selects from the drop-down list (3) the list closes, making XXX the on-top window again, and the macro begins running again (4) the application very quickly opens window YYY on top of XXX, based on the selection from the drop-down list, while the macro is still running (5) FOR SOME UNKNOWN REASON, window XXX apparently regains focus, which is recognized by the application (not the macro), and the application closes window YYY (bad!) If I increase “Delay 100 ms” to a longer delay, then everything works fine – window XXX does NOT regain focus after window YYY opens, so window YYY remains open. It is somewhere around “Delay 700 ms” that the problem disappears. Yes, I know it makes no sense. Ideas, anyone?

That was going to be my guess, too, as to where you would find the delay. Perhaps you could take some timings, ME3 vs. MEP, and forward to ISS -- though I suspect someone there has already seen this posting and taken note of your findings. I think you have narrowed it down enough so ISS can zero in on the scan logic and see where they went wrong between ME3 and MEP. It would be interesting to know whether the length of your match string makes a difference in how fast it runs. You could, for example, scan the input string for only the first character of your match string. When found, do a straight compare of the whole match string starting at the "hit" position of the single character. Repeat until the input string is exhausted. I'd be curious whether that would run faster than scanning for the whole match string. It might, if MEP uses different logic to find a single character vs. a string.

Right. Not ignoring you, just don't have an answer. Your workaround is your best bet for now.

Even with ME3 I have found "Text Type: Use Clipboard" to be very unreliable. Often the target field winds up with only the letter "v" in it. I have found it very reliable to save a text variable into the clipboard, then <CTRLD>v<CTRLU> followed by Wait for Text Playback.

Cory's comments are interesting, concerning MEP being faster at a lot of things. Even with ME3 I have found that timing is the biggest issue by far in getting macros to run properly with multiple computers, different network and server delays, and so on. Ironically, the faster the computer, the greater the problems especially with a web-based or server-database application where the application doesn't necessarily keep up with ME's typing speed. Think about your own manual interaction with the computer -- sometimes you have instantaneous response time, next time the same interaction may hang for several seconds. The most useful ME statements I have found, for these cases, are (1) keystroke speed, (2) mouse speed, (3) wait for text playback, and (4) delay 100 ms. Unfortunately you sometimes wind up programming for the lowest common denominator; that is, slowing everybody down to satisfy the worst case.

Can you provide a little more detail? I am not clear on what you are trying to do.

Here's a very basic example that moves from coordinates 200,200 to 700,700. Works smoothest if you set ME to use the high-speed timer. You would have to calculate the repeat count based on beginning and end points. And the stepping for one of the two variables would seldom be '+1' in each pass through the loop -- if you were moving down only 300, and across 500, for example, you would want to add to N1 in only 3 out of every 5 passes through the loop. Variable Set Integer %N1% to 200 Variable Set Integer %N2% to 200 Repeat Start (Repeat 500 times) Mouse Move Window %N1%, %N2% Variable Modify Integer: %N1% = %N1% + 1 Variable Modify Integer: %N2% = %N2% + 1 Delay 3 Milliseconds Repeat End

Well, don't keep us in suspense ... how did you fix it? And don't feel too bad about the time. I once spent 12 hours looking at 4 lines of assembler-language code before I figured out why it didn't work.

Is is possible the copy-to-clipboard is just taking an excessive amount of time? I have seen great variability in how long it takes for a CTRL-c to finish. 250 ms is not enough. You could try putting a LONG delay, say 3 or 5 seconds, after the copy -- just for validation purposes. If that makes it 100 per cent reliable, then you know the macro is in fact working, and we can work on the timing to get the delay down to something reasonable.

When you click on the listbox item, is the macro running but not successfully copying? Or is the macro not running at all?

Right after your GET PIXEL command, put in a temporary debugging statement TEXT BOX DISPLAY and in the body of the text put %N3%. That will show you what color value is actually being found at coordinates 700,425.

First, put the colors into integer (N) variables, not text (T) variables. Variable Set Integer %N91% "4E9258"(The color green I'm looking for) Variable Set Integer %N92% "3C2610"(The color I don't care about) And use decimal, not hex values -- you'll have to translate them unless you use the mouse locator tool as Brain Virus suggested to find the actual screen colors. Your next line is OK: Get Pixel: Screen Coords: 700,425 into %N1% But testing N1 for zero or one does nothing for you; it's not a boolean value. Instead, compare it to N91 or N92: If Variable %N1% = %N91% ....

I don't think you can say "if color under mouse". You get a pixel color from specific screen x-y coordinates, independent of where the mouse is. So if you WANT the mouse involved, first GET MOUSE POSITION into Nx, Ny then GET PIXEL COLOR AT Nx, Ny into Nz then IF Nz = [green] etc. etc. Be aware that GET MOUSE POSITION is not instantaneous. If the mouse is moving when the command runs, there may be some "slop" in the position coordinates returned in Nx, Ny. Also, if your macro will run on more than one computer, you may need to check for a range of color values. "Green" is not necessarily the same value on a PC running 16-bit color vs. 24-bit color vs. 32-bit color. The only constants seem to be pure black and pure white.

The only similar thing I have seen is, if I edit a timer-scheduled macro, and save it at the same time it happens to run, I'll get a message about the macro file being invalid, and the editor will abend. But when I start the editor again, my changes have been saved properly. I have seen a timing oddity in the editor itself. If I use Alt-d to dup a command, then immediately hit the Enter key to edit the new statement, sometimes it will pop up as a raw statement as if I had selected it from the command list on the left. For example, if the statement I duped was VARIABLE SET INTEGER N44 TO 17, it will pop up as VARIABLE SET INTEGER N1 TO 10 -- the same defaults as if I had inserted it via the command list. If I simply select Enter or Cancel to close the editing panel, then edit the statement again, it is fine. So it's sort of a timing issue like what you are seeing, but probably unrelated because in my case the time delay is very short. Both cases are very minor irritations, makes the day more interesting.