rberq

On the speed issue: does your calling macro set a playback-speed factor? I can reproduce your complaint only by: (1) Setting playback speed of, say, 10X faster than normal in the calling (first) macro, AND (2) Unchecking the ignore-speed-factor box in the delay commands of the called (second) macro. When run stand-alone, the second macro has no speed factor in effect, so timings are just as coded. When called, the second macro runs according to the speed factor set in the caller. Make sure that "ignore speed factor" is checkmarked in all the delay commands, and see if that fixes it.

This has always been a fuzzy area for me, if only because I can't find a clear description in the Help system. But here's an experiment. Consider the following macro: Text box display %T1% %T2% %T3% Variable set string T1 = a Variable set string T2 = b Variable set string T3 = c Text box display %T1% %T2% %T3% Every time you run it, the first display will be blank (no values) and the second display will be "a b c". So, it appears that variables have no value carried over from previous macro executions. Now run a second macro consisting solely of Text box display %T1% %T2% %T3% Every time you run it, the display will be blank (no values). That is true even if you run the first macro and then the second -- the display will still be blank. Now, add "Save all variables" to the end of the first macro, and "Restore all variables" to the beginning of the second macro. Run the first macro followed by the second. The first display from the first macro will always be blank. The second display from the first macro will be "a b c". The (only) display from the second macro will be "a b c". So it appears that all variables are empty by default when a macro begins, and values set within a macro are discarded when the macro ends, UNLESS save and restore are used. The exception to this rule is, when the MACRO RUN command is used to call one macro from within another, the called macro automatically inherits all values existing in the caller. Saved variable values do not survive a shutdown and restart of Macro Express. I only tested with text variables. You could extend the test to include decimals and integers. My guess is that they act the same way.

I have a IE6 web-based application with 10 possible web pages that may appear, all with the same window title but (obviously) with different content. I need my macro to identify which page is currently appearing. I can: (1) Alt-View Source, and analyze the text that pops up in a Notepad window. . (2) Edit-Find text unique to each page, copy to clipboard, and analyze whether the text was found. (3) Use the Ctrl-a combination to highlight all data on the screen, copy to clipboard, and analyze. The trouble with all of these is, they are visible to the user. Edit-Find is probably the least obvious if it’s a small amount of data. Can anyone suggest an invisible way to retrieve and analyze the text on a web page? The solution is probably there somewhere in ME, I just don’t know where…. Thanks for any and all ideas.

Normal line breaks are carriage-return-line-feed, or x'0D0A' (decimal '1310'). So if your text is in T1, I think this will do it: // .... set up CR-LF in T98 Variable Set %T98% to ASCII Char of 13 Variable Set %T99% to ASCII Char of 10 Variable Modify String: Append %T99% to %T98% Replace "%T98%" with " " in %T1% [all instances]

Look at the Variable commands, especially: Variable Set Integer [Get Position of Text in Text Variable] Variable Modify String [append text, copy part of text, copy whole text, replace substring, save to text file, append to text file] With these commands and some imagination you can find the location of key characters or words in your text, extract pieces and use them to build an output string, append the # divider characters, and write the output string to a text file once you have built it. It helps a LOT if the incoming text is completely predictable -- for example, if Department is always bracketed by parentheses as you show it, if the words Income, Entrydate, Sex, Age are always there to use as delimiters for parsing, and so on.

Copy and Paste your "type" command into a posting here, so we can see exactly what you coded. For example, the command below is what you would call Alt-f if you told someone to enter it manually. In ME, it is Alt Down then lower-case f then Alt Up. <TEXTTYPE:<ALTD>f<ALTU>>

I just went through this problem with another project, where tabbing among fields on the same web site responded differently on IE6 vs. Firefox 3. In fact with IE6 it was not consistent on the same web site even from one time to the next. I do not understand Internet and web sites very well, so this may be total bunk, but: I think portions of a web page can arrive at your PC via different routes over the Internet, and the portions don't necessarily arrive "top to bottom" in the same order they were transmitted. Your browser puts them back together as they arrive at the PC; that's why you see chunks of the page appear in unpredictable order. It's my guess that the random arrival, and the internal logic by which different browsers put all the pieces together, is what make finding the field so difficult with a program. That's my story and I'm sticking to it. See my initial response to your question, at the top of this thread. I have used all three of those techniques with success.

I tried monpasdg's solution with "sign in to your account" on the ebay page, and it worked nicely. Whether it would work CONSISTENTLY on that page, I don't know.

I know what you mean. Tabbing forward or backwards through web pages can be unpredictable. Here are some things that might help. I too would like to hear of an infallible method that doesn't require a lot of pre-knowledge of the page. (1) Is the text box always at the same location on the page, for a given computer? You can give the user a special macro to "train" the computer. That is, open the web page, pop up a ME message telling him to click in the text box, and capture the mouse coordinates when he does the click. Store the coordinates in a file, and retrieve them when the real macro (not the training macro) runs. This requires a somewhat sophisticated user who recognizes that changes to screen resolution, changes to the IE heading data and toolbars, etc. will require him to rerun the training macro. (2) If you know approximately where the text box is, you can scan down the page one pixel at a time looking for the color change of the lines outlining the box. (3) You can verify whether you have found a text box -- though not necessarily whether it is the right one -- by having the macro type something, then HOME followed by SHIFT-END to highlight the typed text, copy it to clipboard, and find out whether the clipboard now contains what you typed. If it doesn't, then you were not typing in a text box to begin with. If it does, erase your trial typed-in text and continue on your way.

Thank you. I have been meaning for some time to look into AutoIt. I guess now is the time.

The first problem with WAIT FOR WINDOW TITLE is, the title is already there (potentially) when the macro starts or at the start of each cycle. That's because IE may already be at the site, just not on the correct page, and the window title is the same for many of the pages within the web site. Second problem is that the title may appear well before the web page is completely loaded. Alas!

I have the following logic inside a Repeat loop. There's a web site address in variable T5. If IE is not already running, the line after Else starts IE and goes to the web site and waits for the page to load. On subsequent Repeat passes IE is already running, so the macro highlights the address line with Alt-d and types in a new site id and we go to the site. Works fine every time with IE6. With IE7, Wait for Web Page never completes, it just hangs forever, regardless of whether IE is running or not when the macro starts. Ideas, anyone??? // Start IE if not running, go to site. // If it is running then ALT-d to highlight // and paste in the site address and go to it. If Window Title "Internet Explorer" is running Activate Window: "Internet Explorer" Wait for Web Page: "" Text Type: <ALTD>d<ALTU> Wait Text Playback Wait for Web Page: "" Text Type: %T5% Wait Text Playback Wait for Web Page: "" Text Type: <ENTER> Wait for Web Page: "" Else Web Site: %T5% [internet Explorer - Wait to load] End If //

If it's a timing issue, perhaps your pixel check is happening before the next window has opened. For an uncertain timing like this, I generally use a repeat loop. It's also easier (and more forgiving on different PCs) if you don't code for an exact color. For example, the following logic allows a nominal ten seconds for the new window to open, then does the click if it hasn't opened in that time. It doesn't ALWAYS wait the full ten seconds; the maximum "wasted" wait time is 250ms if the color changes because the new window has loaded. GET PIXEL COLOR INTO N90 (from the original window) REPEAT 40 TIMES GET PIXEL COLOR INTO N91 IF N90 <> N91 REPEAT EXIT (color has changed) END IF DELAY 250 MILLISECONDS REPEAT END IF N90 = N91 (there has been no color change) CLICK TO OPEN WINDOW END IF The repeat loop will be exited either by a color change, or by the expiration of 10 seconds without change. We don't really know which, so that's why the N90 to N91 compare is repeated after exiting the loop.

Only thing that jumps out at me here is, you are checking a pixel location relative to the screen as opposed to the window. If the window is full-screen that may not matter. You said you tried it with a delay before checking color, to make sure there was time for the window to open prior to your pixel check??? Some color values will change on a PC running 16-bit vs. 24-bit vs. 32-bit color, so if it works on one PC and fails on another, check that.

That is one big mother of a macro. Whoever wrote it, somebody should tell him "work smarter, not harder".

To save yourself a few lines of code, you could initialize N50 to zero, then check T70: SET INTEGER N50 TO 0 IF T70 CONTAINS SIFA SET INTEGER N50 TO 1 END IF That just saves you doing the T70 evaluation twice. As long as no other lines in the macro mess with N50 after you set it to 0 or 1, your checking to skip a block of lines can be anywhere. IF N50=0 LINE1 LINE2 LINE3 END IF Or, if N50 can have values other than 0 and 1, IF N50=1 ELSE LINE1 LINE2 LINE3 END IF

I think I'd try the GET IP ADDRESS first, only because it's almost instantaneous, unlike the ping which could take a second or more. If GET IP ADDRESS turns out to be less than 100 percent reliable, then do the ping in addition to getting the IP, as an extra confirmation.

Can you do the GET IP ADDRESS command before your disconnect, save it in a variable, do it again after the reconnect, and compare to make sure it has changed?

I don't have the .mex file, just the macro itself copied and pasted into an e-mail. I saved it on a ME Version 1.6 system (that's all I had for an old version) and tried your method to get it into 3.7. Got a couple dozen abend messages from ME when it tried to convert. Probably it's not legit to store a V2 macro on a V1 system and try to convert it to V3. I was able to convert it pretty well by editing the text file and getting rid of a lot of < and > characters and replacing > by > at the end of commands. At least most of the commands are recognizable now in the V3 scripting editor and I can clean it up manually from there.

I was sent a macro that is (I think) version 2 of ME. I have only version 3 installed. How do I convert the macro to work with version 3?

I have seen it occasionally, but I don't know the cause. I think it was while I was using the editor. When you say you were "not doing anything in ME" do you really mean you were not doing anything? Or were you using the editor? Sounds like a good question to email to technical support.

I don't know how you launch PMS. However, when I set up a desktop shortcut to run command.com in full screen mode, then your macro works for me first time and subsequent times. Running command.com in a window, I get the same results you do, the text is not captured. So it seems the difference between your results and mine is, in fullscreen mode, MacroExpress keeps working after the first time for me but works only once for you. How does PMS itself get launched? If it is an icon simply launching pms.exe, try changing it to c:\windows\system32\command.com /c pms.exe. If that doesn't do it, then I'm out of ideas.

Try using ACTIVATE WINDOW:pms before, or in place of, the RESTORE WINDOW command. RESTORE relates to sizing, whereas ACTIVATE will simply give focus back to the window. Having said that, your macro (with RESTORE) works fine on my computer in a cmd window, so the ACTIVATE may not help you. I bet the pms acronym gets a lot of jokes. We have one called pms also -- everyone remembers the acronym, no one remembers the full system name.

If that doesn't work (keyboard hooks), then post some more details here for us to cogitate upon. Are you sure your printing macro is ending? If it remains running, then no other macro can be activated.

I see what you mean about the coordinates being always the same. Apparently in Adobe there IS no "text cursor", so even though the MOVE MOUSE TO TEXT CURSOR command does not error out, the mouse coordinates returned seem to be always the upper left corner of the screen. Brandon's original idea of having the macro running before the user selects text MIGHT work, by capturing the mouse-button-down coordinates and then the mouse-button-up coordinates. But in practical everyday use it will probably fail due to timing constraints -- the user simply is not going to pause long enough at the begin and end points to allow the macro to capture the mouse coordinates. The second difficulty I see is, the user may highlight data that spans several screens by dragging the mouse down below the bottom of the screen while the text scrolls off the top. Then, capture of mouse coordinates relative to the screen becomes useless. IF THE DATA SELECTED IS CONFINED TO A SINGLE SCREEN, WITH NO SCROLLING, then I still think what you want could be accomplished by scanning the screen for the selection color, finding where the color begins and ends, saving those coordinates, and using them to re-select (drag the mouse from beginning point to end point) after the highlighting tool has been invoked. The difficulty would be knowing what selection color to look for, adjusting for 16-bit vs. 24-bit vs. 32-bit color, and getting a scan routine that works fast enough.