rberq

I'll just make a few wild guesses. Do you maybe have a CTRLD in your macro without a corresponding CTRLU? Are you dealing with a significant amount of text? If so it might make a difference whether you copy and PASTE, as opposed to copying and TYPING back a large amount of text, where the keyboard buffer might be overflowed and cause problems. Take a look at the Wait for Text Playback command in ME, also the Keystroke Speed command. Also look at Clipboard Type Text, which makes the distinction between typing and pasting which isn't so obvious on the other Clipboard commands. As to two macros open for editing at one time -- if you are alt-tabbing and you see two big "M" icons, it may mean one M is the ME editor and the other is a macro that is still running, though I have noticed this only when the running macro has a text box open.

Now that's scary. I have found by forcing the window to top left and changing size to a standard dimension less than or equal to the Windows setting, my macro works OK on the two PCs I have tested on. From what you're saying, I had best test it on a variety of machines before I can feel confident.

Yes, I played at it today and also found it to be pretty fast. Now I have to lay some restrictions on the users. 16-bit color produces pixel values a little different from 32-bit, but it seems to work OK if I check for a small range of values. But people with exotic color schemes are going to have to come back to Windows Standard. I suppose I could make a macro to examine the screen in question, once at startup, and custom-tailor the color-checker values for whatever scheme the user has chosen. Now it's got me wondering, where in Windows the color gets translated from whatever the application sends, to what is displayed on the screen, and how would I do a reverse translation? Way too much work for what should be a simple process....

I recognize it by the white data entry fields, the gray labels for those fields, a large unused white space at the bottom, and the various darker gray labeled buttons. None of these seems to be a control that can be captured. That's why I'm thinking of color patterns -- other screens wouldn't have fields and buttons at the same places, probably. But I don't know much about Web pages and their constructions -- I was hoping there was some behind-the-scenes data that ME could capture to provide the identification.

I am working with a Web-based application that can display many different screens as the users maneuver through their daily work. The URL never changes. The window title never changes. But when a particular screen displays I need MacroExpress to do stuff. I can schedule a macro to run every second, or I can loop in a macro -- but what do I check for? One suggestion I found on this forum is to use CTRL-a to "select" all screen fields, CTRL-c to get them to the clipboard, then analyze the clipboard data for the known pattern of data. That would work, but would momentarily turn lots of screen fields blue every second, no matter what function the user was engaged in, and the flashing would seriously disrupt their sanity. Another forum suggestion is to view source of the page, store it in a file, then examine the content. That would also work except that the source is popped up in a Notepad window which also disrupts the user. The only other idea I have come up with is to get pixel colors at various known points on the screen and check for an expected pattern of colors. I haven't tried it yet, but it seems potentially unreliable or subject to false positives. Clever tricks, anyone?

I connected from my computer to another using Remote Desktop, and I used ME on the remote PC. But I didn't connect from another to mine. So apparently the feature works even better than you anticipated!

When ME is running, there is a little blue "M" in the system tray. Once in awhile the M will be red instead of blue. Can someone tell me why?

Can a file that starts downloading be resumed as with firefox for example? Sorry, I do not know the answer to that.

I have never used the FTP features of ME, so I'm shooting from the hip here. There's a "FTP Site Command" command in ME, which allows you to send a freeform command to the remote site. Can you send one of the FTP timeout commands to lengthen the allowable "dead" time? Of course, if it is the MacroExpress end that is timing out, that might not help.... You can also do FTP from a DOS-style command window, with a file of FTP commands, instead of using MacroExpress. This might give you access to some of the FTP timeout options that are not available in the limited ME command set.

Glad we could help. Here's another possibility using only ME. Instead of looping in your first macro that checks for file existence, schedule it to run every second or two or whatever is appropriate. Then write a second macro that is activated by the appearance of the window you are watching for. (Just make sure you set Options | Preferences | Caching | Enable Window Activation Caching.) When the window appears this macro will be interleaved between scheduled executions of the first macro. This one can set and save a variable value to signal to the first macro that the window has appeared, if that's what you need. Or store an indicator in an environment variable which the first macro can access on its next execution.

I give up. How about Stan's suggestion to write a new, one-line macro on her PC? Did you try that?

You said, "It's as if her system isn't reading the keyboard shortcut for the macro...." Did you check Properties for the macro, on her computer, to be sure the activation keystrokes are still set? I have had occasional problems like that when there was already a macro on the system with the same activation sequence. Also double-check that the macro is not disabled on her machine. I know these sound like insultingly simple suggestions, but since I have made both mistakes more than once I don't feel bad about recommending them to you....

Try using <ALTD><TAB><ALTU>, if the key sequence wasn't captured that way. In other words, Alt Down is equivalent to pressing and holding the Alt key; then Tab is pressed and released; then Alt Up releases the Alt key. When you think about it, that's really what you are doing when you manually tab from window to window -- you may hit the tab key several times to cycle through a series of windows, before you finally release the Alt key. If it still doesn't work, maybe you can use Activate Window to switch back and forth based on the [partial] window title. That may be more reliable overall if you have more than just the two windows running.

Yes, you definitely can export just part of the registry using command line parameters. Again, just do a Google search. I believe you just put the piece you want at the end of the command: regedit.exe /e destinationfile.txt [HKEY_LOCAL_MACHINE..........

Try Clipboard Copy (CTRL-c) instead of Clipboard Start Copy / Clipboard End Copy. I can't quite figure out what the Start Copy / End Copy do, but it is NOT a standard copy-to-clipboard.

Like a fear of high places, being shy about messing with the registry is a healthy instinct. However, you can run regedit.exe as a batch command, with an option to put the registry out to a text file. Then you can use ME to examine or play with the text file to your heart's content, without worrying that you will damage the actual registry. Do a Google search of regedit command line options. I believe the command is "regedit.exe /e filename.txt".

Wow! My macros flip back and forth among 8 screens, and I was doing a just-in-case Activate Window before typing into each one. Checking whether the window is already on top, and skipping the Activate where it is, makes the overall process significantly faster.

"If Not Window Title "Outlook" on top" Thanks, Kevin. I will try adding that ahead of my Activate / Wait sequence. Anything to speed things up!

Thanks for the ideas, Cory. I also have found it helps to Activate the window just before typing, even though the macro itself was activated by the appearance of the window. Activate Window wasn't quite enough, so following the Activate Window I added Wait for Window Title. And when even THAT wasn't quite enough, following the Activate and the Wait for Title, I added Set Always On Top. I hope that will finally do it, because there's nothing more to add!

The Outlook pop-up seems to stay in the background if I use the command "Set Window Order: Set "xxxx" to always be on top" in my macro. So far it's working....

Thanks, John. I'll take another look. I can turn "notify" on and off within Outlook. I will look closer and see if there is an on-top vs. not-on-top option.

I have a half-satisfactory solution. I store a "master"' macro file on a network drive, and I can update that whenever I want. Each user has his own macro file on his C: drive, which is refreshed from the "master" by a simple copy-file prior to ME startup when the PC is rebooted. (I also start ME in the batch file that does the file-copy.) So far I haven't had to update macros mid-day, but if that becomes necessary I will give users an icon to a batch file that ends ME, refreshes the macro file, and restarts ME.

I may be typing along rapidly in a Microsoft Word document, when Outlook pops up a box saying "New mail has arrived. Would you like to read it now?" At that point, most of my typing is ignored because focus is now on the pop-up. If I happen to type a letter Y or N, the pop-up accepts it and either brings up the email (Y) or closes the pop-up (N). I have a similar situation with ME. A macro is busily tabbing from field to field and typing data into a form, when up pops the Outlook box and steals focus and steals all the keystrokes until either Y or N happens to occur, and then if it is Y the email is displayed. In any case, the macro application is totally disrupted. Short of disabling the Outlook feature, can anyone suggest a way around this?

I may be misunderstanding your problem. If so route me to the bit bucket. I have a VB application that displays several windows with different titles. The windows contain text box controls which the application has put data into. A separate macro is activated for each window based on window title. The macro does a Get Control for each text box, then a Get Control Text to "read" whatever data is in the text box. So maybe you could recognize your many different windows by starting an independent macro for each distinct window title. As to capturing controls inside the window, I'm not sure if mine works simply because the windows are always in the same location, or whether it would work with random locations like you have. I guess I should check that out ... maybe what I considered to be so clever is working only because of dumb luck.

I don't mean to disparage Namino's idea, it may be great in a private environment that you control. But if you are writing production macros for use on many PCs, the ram-disk software is one more non-standard thing to install and maintain on all those PCs.... If it's not vanilla, somebody's going to be allergic to it.