acantor

This script does the trick nicely enough. Text Type (Simulate Keystrokes): <TAB><TAB><TAB><SPACE> // Navigate to the checkbox, uncheck it. Text Type (Simulate Keystrokes): <SHIFT><TAB><SHIFT><TAB><SHIFT><TAB> // Navigate back to "Variable Name" Scope = Global Activation = "Variable Properties" is opened. Obviously, this script, as written, resets the checkbox to global if you open the window again. But I wanted to see what I could up with in under five minutes.

Create a Macro Express macro that is activated by the "Variable Properties" dialog box gaining focus. The script checks the state of the "Make this variable to macros called by this macro" checkbox by sniffing for pixel = black. If it's found, uncheck it. It's not an ideal solution, but if there are no registry hacks, it's better to spend 10 minutes writing a macro than to manually change the setting dozens or hundreds of time.

I won a T-Shirt for this set of macros in 2004! Although the scripts were designed for Macro Express 3, updating them for Macro Express Pro should be straightforward. "Escape to Close"

Agreed... it's intuitive, at least for people who became acclimatized to using Esc to exit screens in earlier versions of Windows, and in DOS. I have an window-specific macro that sends <Alt><F4> when the title contains "Help". It allows me to close any Help screen by pressing Esc, just the way it used to work in Windows 95 and 98. (There is, however, a tiny side effect. If a document or file has "help" in its name, pressing Esc will initiate an exit!)

Welcome, Arekowczarek!

hi Terry, I see the problem. You want this: Text Type (Simulate Keystrokes): <CONTROL><F4> Not this: Text Type (Simulate Keystrokes): <CONTROL>F4

You can also use the standard Windows "close" hotkey, Alt + F4 to exit the Scripting Editor. If you have modified the script, you will be prompted to save (or not). Or, do what I do. Write an application-specific script for the Scripting Editor. I use Esc to activate it, but you can choose anything you want. The script consists of one line: Text Type (Simulate Keystrokes): <ALT>sc This is the equivalent of choosing "Close" from the "Script" menu. I write a lot of macros triggered by ESC that close windows. I currently have 18 of them!

I cannot replicate this. If I close the Script Editor without saving a macro, the "Modified" column is exactly as it was before I opened the macro for editing.

If the window you want to capture is a message box, try using Ctrl + C to copy the text to the clipboard. make sure that the message box has focus, or that your script transfers focus to the window. Once the text is in the clipboard, it's a snap to process.

Something I have found when hunting for mouse pointer changes. There are situations when the only way I was able to make the script work was to "wiggle" the mouse pointer before testing its shape: // Check mouse cursor... // But the cursor must be "wiggled" before testing! (Delays alone are not effective) Mouse Move: 2, 0 Relative to Last Position // Wiggle starts now... Mouse Move: -2, 0 Relative to Last Position // Wiggle some more... Mouse Move: 0, 2 Relative to Last Position // Wiggle more... Mouse Move: 0, -2 Relative to Last Position // Last wiggle... Delay: 5 milliseconds If Mouse Cursor: Arrow Mouse Left Click Repeat Exit Else Continue End If

You can combine these techniques, as well. For example... Check horizontally, left to right, one pixel at a time, starting at (100, 0) for pixel colour 1234. Let's say it's found at Y = 200. Check vertically, moving upward one pixel at a time, starting at (100, 200) for cursor shape XYZ. Click! --- I have written many macros that perform pixel by pixel hunts, and I can tell you that the macros are either extremely reliable or extremely unreliable. I use these techniques when it is not possible to gather underlying information from the application. The scripts infer what is happening "under the hood" by inspecting the user interface, and gathering clues. So there is a lot that can go wrong. I keyboard-enabled Hotmail and Goggle Maps a few years ago, and both worked well until Microsoft updated the look-and-feel of Hotmail, and Google added new widgets. In both cases, it was back to the drawing board.

I updated one of my clients to Macro Express Professional -- it was for me really, as the added functionality makes my life simpler -- but after a couple of weeks, the macros proved to be so unreliable that she asked me to revert back to to the old version. Almost all of macros were hotkey activated.

It is not possible to create free-standing programs with Macro Express. Free-standing macros can be made, but Macro Express must be on the system.

Whether or not colours vary with OS, display settings, video card, or whatever, this sounds like a situation where pixel hunting might reduce complexity. Although it might be necessary to manually set a few values, once running, a macro hunting for pixel colours is an accurate way to differentiate windows. For example, I have scripts that do things like this: A. Search along a horizontal line for a pixel of one colour. B. Search along a vertical line for a pixel of another colour. C. Determine the pixel colour at position x, y. If A and B are found, and C = abc, assume this is screen 1 If A and B are found, and C = def, assume this is screen 2 If only A is found, assume this is screen 3. If only B is found, assume this is screen 4. Otherwise, signal that the screen is unknown. Macros like these are never *truly* elegant. As I mentioned earlier, I use techniques like these as a last ditch effort. But once you have a handle on the techniques, they can be powerful ways to zero in on screen objects, or infer information about a window. Maybe the question should be this: If Macro Express had a fast pixel search command, do you think you would find ways to use it?

I use "pixel hunting" strategies as a last ditch effort, when all else has failed, to locate, click on, or to give focus to screen objects. Recently I developed over 50 scripts for a non-standard application that had no detectable controls, and displayed no cursor changes. But there were unique colours in predictable areas of the screen, and I developed many scripts that took advantage of the pixel colours that were visible, or could be made visible via scrolling. To my surprise, these macros have proven to be extremely reliable and stable. I could find no other way to get the job done. It was not possible, for example, to move the mouse cursor to a specific coordinate, because the location of the target changed in response to the user's input. Normally, my pixel colour macros do not search large regions. They usually check pixels along a single vertical or horizontal line, so run reasonably fast. But recently, I encountered a situation where the target colours could appear anywhere on the screen. Macro Express was not up to the task. I ended up using AutoHotkey for this script, but I wished that I could do the same thing in Macro Express.

I have a challenge for you all! There are occasions when the most reliable way to target a screen object is to "hunt" for a pixel colour that appears only in that object. For example, in the ME Pro Script Editor, in the default "M" icon to the left of the "Macro Nickname:" label, there is one pixel with colour = 7004146. (The "Mouse Locator" shows positions of the pointer as well as pixel color.) The AutoHotKey "PixelSearch" command is lightening fast, and easy to use. There is no equivalent command in Macro Express. I have put in a feature request. Hopefully, our friends at Insight will come through with a new command. But in the meantime, I need a way to search for a pixel in Macro Express. It was not horribly complicated to write a ME script to search for a pixel colour within a specified region (e.g., a rectangle). But my script runs slowly. For example, on my PC it takes 15 seconds to test a 400 by 400 pixel rectangle. AutoHotKey's PixelSearch chews through 1280 by 1024 pixels in under a second. I would welcome suggestions on how to make this kind of script run faster. If you are going to experiment with my script: 1. My script contains several disabled lines that I enable for testing. However, these lines are not disabled in the codebox. I suggest that you import the attachment. Otherwise, the script will run even more slowly than usual. 2. The macro that I exported is activated by Shift + Ctrl + Alt + \, which you may want to change. // Search a rectangular region of the screen for a pixel colour // Start at the top-left. Move right along a horizontal line, testing each pixel. At end of row, go to start of next line, and try again. // (Enable the disabled lines for testing and debugging) // Specify pixel colour to search for. Use "Mouse Locator" to obtain value, or use one of the values below... Variable Set Integer %PixelTarget% to 7004146 // This colour appears in the ME Pro Script Editor, in the "M" icon to the left of "Macro Nickname:" Variable Set Integer %PixelTarget% to -1 // This colour never appears. Enable this line to test for case when pixel cannot be found // Specify (x, y) of the top-left corner of the search rectangle... Variable Set Integer %xStart% to 0 Variable Set Integer %yStart% to 0 // Specify (x, y) of the bottom-right corner of search rectangle... Variable Set Integer %xEnd% to 400 Variable Set Integer %yEnd% to 400 // Calculate length and height of search rectangle: Variable Modify Integer: %xLength% = %xEnd% - %xStart% Variable Modify Integer: %yHeight% = %yEnd% - %yStart% // Set coordinate to test. (Start in upper-left corner)... Variable Set Integer %xCurrent% to %xStart% Variable Set Integer %yCurrent% to %yStart% // Start with the first "row" of pixels. We test up to yHeight rows... Repeat Start (Repeat %yHeight% times) // Test each pixel along a horizontal line xLength pixels long... Repeat Start (Repeat %xLength% times) Get Pixel Color at (%xCurrent%, %yCurrent%) Relative to Current Window into %PixelColour% Mouse Move: %xCurrent%, %yCurrent% Relative to Current Window // Use for debugging. Lets you see search progress, but it's slow! If Variable %PixelColour% Equals "%PixelTarget%" // Pixel found... Mouse Move: %xCurrent%, %yCurrent% Relative to Current Window Text Box Display: Found! Macro Stop Else // Increment x so we test next pixel to the right... Variable Modify Integer %xCurrent%: Increment End If // Continue until the entire row is tested... End Repeat // Reset x to its original value, and increment y so we can test pixels in the next row... Variable Set Integer %xCurrent% to %xStart% Variable Modify Integer %yCurrent%: Increment End Repeat // Pixel not found... Mouse Move: %xEnd%, %yEnd% Relative to Current Window Text Box Display: Not Found! Pixel_Search.mex

Try creating a script from scratch. It could be a conversion issue. I sometimes use a "homeopathic" approach to debugging scripts: I add something to the script that causes the symptoms to appear. In this case, try forcing a drop-down list to open. Depending on the context, the keystroke may be <Alt><Up>, <Alt><Down>, or <F4>.

Have you tried inserting a "Macro Stop" command after copying information to the clipboard, and then manually checking its content by pasting it somewhere? If you discover that the content of the clipboard is what you expect it to be, try copying it to a text variable. Then check the value of the variable, and see whether it matches the clipboard. If I were trying to parse information, I would rather manipulate a variable than the clipboard. Finally, your method for copying information to the clipboard might affect things. A method that works in one macro may fail in another. You should try both "Clipboard Copy" and "Text Type<CONTROL>c". In one situation, neither of these techniques worked for me, but I found that "Clipboard Cut" did the trick.

I wonder whether this is some kind of timing issue. Certain operations take longer to complete than we might like, and in those cases, one of the only recourses we have is to insert time delays into our scripts. Clipboard operations often require a little extra time, so you might want to add short delays before and after copying text to see if it makes a difference. Start with 1000 ms, and if your macro works, decrease the delay or delays until it stops working reliably. When I find I need to insert delays, they are usually 100-300 ms. on occasion, five or 10 ms is all it takes.

There are ways to "landmark" on a webpage so that text can be selected more reliably than than by mouse emulation. 1. This approach works when you need to copy text in an edit field. Search for unique text that is either just before or just after the target field, and then either send "Tab" or "Shift Tab," one or more times, to give keyboard input focus to the field. Unless there is some weird JavaScript happening under the hood, the text will be selected when focus arrives in the field. Sometimes, cutting the text works more reliably than copying it. 2. Use Firefox. By changing certain program settings and installing certain add-ons, it is a snap to find, find again, and select by keyboard. I have built many macros that take advantage of Firefox's ability to give focus to select text via the keyboard.

Complex macros like the one you are developing take a long time to develop and perfect. There are no shortcuts. Only one approach that I know of is effective at figuring out where a subtle (or a not-so-subtle) problem lie. Work iteratively: create a few lines of code to perform part of the task, and test repeatedly. When you are sure that it works, add more code to perform the next task, and test again. Slowly and surely, this approach yields results. But there are not substitutes for trial and error, time, and creativity. Overall, I would describe the approach as an incremental exercise in problem-solving. If at some point, you discover a more reliable (or faster, or more elegant) way to perform a sub-task, you may or may not be able to salvage what you have done before. That's part of the dubious pleasure of macro development! I had a quick look at your code, and although I don't understand the particulars of what you're trying to do, I think you are off to a good start. Adding more comments would help, but overall, it looks promising. But I would make one suggestion: See where you can change statements like this: Text Type (Simulate Keystrokes): <CTRLD>f<CTRLU> To this: Text Type (Simulate Keystrokes): <CTRL>f Over the years, I have learned to avoid <CTRLD> and <CTRLU>, as well as the analogous commands for Alt and Shift, unless absolutely required. I find they lead to unanticipated and unpredictable problems further on. If you are using this code to initiate a search, <CTRL>f will work in most contexts. The main "side effect" of this approach is figuring out how much of a delay to add before (rarely) or after (usually) the command to ensure that it works reliably enough.

If a text box has focus, Ctrl + A should select only the content of the box.

Here is how I do it: Clipboard Empty Clipboard Cut ' Add short delay If Clipboard Equals "" ' Do this Else ' Do that End if

It is possible to run macros on a schedule, but what you might want is a macro that is activated by an event, such as a specific web page appearing.

There are a lot of ways to script this with Macro Express. The technique or techniques that work for you will depend on how you have configured Firefox, the uniformity (or lack of uniformity) of the Craigslist pages you are accessing, and more. The best way I know to built a complex macro like this is to script one step at a time. Script and test... add the next step... test... repair... add another step... change the approach you used in an earlier stage based on what you have learned subsequently... script and test some more... etc. It's time consuming, but if you have a "macro personality," you may find it very satisfying! Because the task involves a series of complex steps, I can guarantee that you will face timing issues. So you need a good way to infer when each task is complete. Inserting timed delays will not be reliable, unless you choose overly long wait times, say 5 or 10 or 20 seconds between steps. This is inefficient, as a step may only take a fraction of a second 90% of the time. But you need to plan for network bottlenecks and other factors when scripting tasks that take place in a browser. There are no built in MX commands to detect when Firefox has completed tasks, so you will have to make them from scratch. One strategy is to monitor a pixel. When the pixel at (x, y) turns a certain colour, a task is done. Another strategy is to monitor the shape of the mouse pointer at coordinates (x, y). When it changes from Shape "A" to Shape "B," assume the process is complete. If my description in the previous paragraph is hard to understand, ignore it. It is perfectly OK to use timed delays. If your script works reliably with delays, more power to you! I try to avoid them, but sometimes they are necessary. It's easy to find and select text in Firefox via keyboard and via mouse. In general, navigating by keyboard is more reliable than navigating by mouse for scripting purposes. There are setting changes (Tools > Options) that improve keyboard access. For example, you can do something like this to copy the line of text that appears after the word "Hello!": [This is MX pseudo code] Type Text <CONTROL> f ' Search mode Type Text Hello!: ' Search for "Hello!" Type Text <ENTER> ' Initiate search Type Text <ESCAPE> ' Cancel search Type Text <RIGHT> ' Move cursor off selection. Type Text <SHIFT><END> ' Select to end of line Type Text <CONTROL>c ' Copy Some Add-ins also may make it easier to find and select text via keyboard. Personally, I almost never need to reach for the mouse with Firefox, and this fact contributes to the reliability of some of my Firefox macros. It sounds like an interesting project!