acantor

I know a clunky way to modify the font colour in Excel: Press "Ctrl + 1" (opens the "Format Cells" dialog box. That's a number one, not an L.) Wait for the dialog box to open. Press "N" to navigate to the "Number" tab. Press "right arrow" twice to navigate to the "Font" tab. Press "Alt + c" to navigate to the "Color" drop-down list. Press a sequence of keys involving "Home," "End," and the four arrow keys to pick a colour. Press either "Enter" or "space" to finalize your choice. Press "Tab" to move the focus off the drop-down list. Press "Enter" to do the equivalent of clicking on the "OK" button. All of this is easily automated with Macro Express. My guess is the only place you would need to insert a time delay is at Step 2. A more elegant way to do this would be to use VBA in Excel… But let's not go there!

Duplicate message!

Ah, yes, focus problems!!! I have been there. Try a different approach. Maybe use two "switch to window" commands in a row, with or without delays. Or leave out the "wait for window title" and substitute a time delay. Or check pixel colours to infer when the second window is ready. For debugging, you might want to break the macro down into several, and ensure each part works as you expect. How about experimenting with a macro triggered by the appearance of the second window?

Hello Doug, All I can tell you is that you are going about this in exactly the right way. There are no pat answers to your questions, but the way forward will be revealed, eventually, through trial and error experimentation. My own experience is that developing a working version of a complex script, like the one you're describing, can be done relatively quickly with Macro Express; but making it virtually 100% reliable takes perseverance. (100% reliability is extremely difficult to achieve, but we can come close.) Sometimes, when dealing with multiple windows, a short time delay (say, 250 ms) after switching to the second window makes the crucial difference. I often use "wait for window title" in these situations, but on occasion, I have found the time delay works equally well. (But it is not as elegant…) For some windows, you may find a script works better if you wait for the window to gain focus; in other circumstances, it works better to wait for it to open. Figuring out the best approach is as much art as science. (Maybe it's even more art than science…) You may or may not get better results detecting and acting on controls rather than windows. Again, there are no guidelines or rules. It comes down to figuring out which tact works best.

Hi Kevin, I use <ALTD> and <ALTU> only when <ALT> does not work, which it almost always does. And when I am forced to use the up and down versions, the key sometimes get stuck in the down position. Are there guidelines on when to use plain modifiers, and when to use the up and down versions? In other words, are there advantages (and drawbacks) of <ALTD>, <ALTU>, <CTRLD>, and <CTRLU> compared to <ALT> and <CONTROL>?

You can press Ctrl + N in the Scripting Editor to disable a line of code that has focus; or you can select several lines if you want to disable more than one line. The same hotkey re-enables the line or selected lines.

What I meant to say, Terry, was that JavaScript or Ajax running in the background of your brain's software was responsible for the erratic behaviour! I'm glad you figured it out. I can't count the number of times a script has ran amok because of a trivial error.

It sounds like a problem caused by JavaScript or Ajax or some other scripting that happened in the background. I faced similar problems while automating my Hotmail login. The solution that worked for me was to dramatically increase the time delays between steps, up to 2500 ms. You might also try sending the keystrokes via the clipboard. My guess is that you could eliminate many of the delays in the script without compromising reliability. But experiment with adding very long delays at the point where the script fails.

Members of this forum might be interested in this two-day course on software customization that I will be teaching. One of the modules is on Macro Express Pro, with a focus on how to "recycle" MEP macros as NaturallySpeaking voice commands. For more information: http://www.cantoraccess.com/presentations/presentations.html#scripting2010

For example, I have ten hotkey macros for the Script Editor to automate the accessing of the commands I use most often, including Mouse Move, Delay, Repeat, and Text Type. In the "Text Type" window, I use about ten ShortKey macros to insert the keystrokes I use most often, including <ALT>, <CONTROL>, <ARROW RIGHT>, <ENTER>, and so on. I also use ESC as a hotkey to close the Script Editor and return to Macro Explorer; to close the Direct Editor and return to Macro Explorer; and to close the "Text Type" window.

I have never checked! Early releases of ME Pro had "issues," but these are increasingly going by the wayside. I have not experienced any significant problems with the two most recent versions of MEP. The user interface in MEP is more complicated than ME3, but there is an obvious solution: use MEP to streamline access to MEP! Since its release, I have accumulated almost 40 macros to simplify interaction with MEP, 30 of which I have used during the past month. In fact, when I teach classes about Macro Express, one of the exercises I assign is to script a macro to automate a task in Macro Express.

You're right! The feature is not available in ME3, just in Pro.

Alt + space is one of the most useful keyboard shortcuts that I know. I use it dozens a time a day, and it can form the basis for many scripts. Alt + space activates the window's System menu, and virtually every window has a System menu, including applications, documents, dialog boxes, message boxes, and more. Almost any window can be closed by pressing Alt + space, followed by C (for Close).

I have spent a fair amount of time figuring out ways to determine when a Firefox page has loaded. I have not found a single solution that works on every web page under all conditions. The best of the solutions are not 100% foolproof, but are good enough. Most of these macros monitor pixel colour changes; others monitor changes in the shape of the mouse cursor. A few do both. Note that the wait for IE webpage command is not 100% reliable, either. JavaScript and AJAX appear to throw off the timing. So even when I script for IE, I am usually forced to add a time delay.

There is no reason (that I can think of) why the "standard" hotkey for paste shouldn't work in cmd.com. I used Macro Express to assign Ctrl + V to send the sequence of keys for pasting when I am using the console.

Macro Express must be running, but no macro. The script that I outlined is activated by the closing of a specific window.

You can't use Ctrl + V to paste in cmd.com. But you can do something like this: Alt + spacebar E (for Edit) P (for Paste)

It takes time and effort to make macros work reliably. There are no shortcuts to success, except putting in the hours and doing a lot of trial-and-error experimentation. I find macros triggered by control events can be tricky to script. When they work, they work beautifully, but getting there can be circuitous. Sometimes, strategic time delays inserted into the script is all it takes. On occasion, I have switched control activations to window (or other) activation because there was either no advantage, or no way (that I could find) to make the scripts reliable. You might want to try chaning the copy command to <CONTROL>c. It's probably not the reason your script isn't working reliably, but with all macros, simplicity is a virtue!

There are likely several ways to activate a macro when a window closes. The simplest approach: Create a new macro. Choose "Window Title" as its activation. Specify the window name. From the drop down list, pick "event to activate on" = "Window is Closed."

What you are using it for? Deleting the character to the right of the insertion point in a text editor? Deleting an email message or a file?

Show us an example of a macro that no longer works.

What scope are you using? It probably should be set to "Global." I have made several macros that are activated by window titles, and the ones that work reliably required trial and error before they worked. You may need to experiment with variations such as whether the trigger is the window gaining focus, or the window opening.

I submitted a bug report, too. I have submitted many bug reports and feature requests over the years, and while Insight has not acted on every one, I have seen a lot of problems fixed. I think Insight is better than most.

It might be a bug. I can send certain keystrokes, such as "Hello" and <ENTER> to the control, but <BACKSPACE>, <DELETE>, <SHIFT><HOME>, <F3> and <ALT>f insert the literal keystrokes. When I mixed and matched strings that work with those that don't, things get stranger. Hello<ENTER> works, but not Hello<BACKSPACE>.

<GET CONTROL Flags="1" Program_Name="NOTEPAD.EXE" Class="Notepad" Title="Untitled - Notepad" Control="\"Edit\",\"1\"" Variable="%Control%" Caption="Untitled - Notepad" Partial="FALSE" Wildcards="FALSE"/> <DELAY Flags="\x02" Time="250"/> <TEXT TYPE Action="2" Control="%Control%" Text="Hello! "/> Here is another example. You must have an *unsaved* Notepad document open. Its title bar must read "Untitled - Notepad". Notepad can be minimized or behind another window, but it has to be open! Choose hotkey activation, ensure that Scope is global, and have fun.