Jump to content
Macro Express Forums

acantor

Members
  • Posts

    1,532
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by acantor

  1. I don't think it's possible to activate a MEP command by "double clicking" a modifier key. But I think you could make it work with an alphanumeric key.
  2. Maybe we are grasping at straws, but consider creating a window or application-specific hotkey macro for Macro Express, triggered by, say, F10, that either clicks on the toolbar icon or chooses the command from the menu. You could probably choose F9 as the activation, if you wanted.
  3. Cory, Have you assigned F9 as an activation for any macro? Does the problem occur when you choose the "Test Run" command from the "Debug" menu?
  4. Hi Cory, I just tried using F9 with two long scripts, including one that has 200 lines, 40 if statements, and dozens of variable manipulations. I have not been able to reproduce the problem, but I will keep an eye out. I am using a Windows 7 64-bit machine, with the most recent version of Macro Express.
  5. I just noticed that you are using Macro Express 3 rather than Macro Express Pro. The same principles apply, but you will probably need to start from scratch rather than using my code snippets.
  6. Does the title really end in a period? End of Report. By any chance did you type in the title? It's usually better to capture a title than type it. Ensure the End of Report message box is visible before proceeding. In your script, choose the "Wait for Window Title" command. Click the "Browse" button. You should find the window title on the list. Choose Partial or Exact match, and the maximum wait time. If you don't see the message box listed, it may be a non-standard pop-up, in which case MEP cannot "see" it. You will need to resort to other techniques! You may also need to insert a short time delay between the two statements.
  7. Here is the code to differentiate single, double, and triple clicks. (Unlike my previous example, this version does not check for cursor movements.) Because the shortest available wait for left click is 1 second, there is a pause after a single or double click that some may find unacceptable. A triple click, on the other hand, is recognized almost instantaneously. I will submit a feature request for shorter wait times! Wait for Left Mouse Click On Error Catch Error: The condition was not met within the specified amount of time Text Box Display: Single click detected // Insert commands for a single click Macro Stop End Catch Error End Error Wait for Left Mouse Click On Error Catch Error: The condition was not met within the specified amount of time Text Box Display: Double click detected // Insert commands for a double click Macro Stop End Catch Error End Error Text Box Display: Triple click detected! // Insert commands for a triple click
  8. 300 seconds is the maximum time to wait. If the window appears earlier, no problem. But while waiting for it to appear, hands off the keyboard and mouse! You may be able to avoid a macro that runs continually for up to 3 minutes per loop by scripting a second macro that gets activated when the window appears. If the message box has a unique title, this could be quite doable.
  9. Get Mouse Position into (%XMouse1%, %YMouse1%) Relative to Current Window Wait for Left Mouse Click On Error Catch Error: The condition was not met within the specified amount of time Text Box Display: Single click detected Macro Stop End Catch Error End Error Get Mouse Position into (%XMouse2%, %YMouse2%) Relative to Current Window If Variable %XMouse1% Equals "%XMouse2%" And If Variable %YMouse1% Equals "%YMouse2%" Text Box Display: Double click detected! Else Text Box Display: Two clicks detected, but the mouse was moved between clicks End If The activation for this script is left click on the title bar. I set "Wait for Left Mouse Click" to wait up to one second (which appears to be the shortest time interval available.) If you click on the title bar once, the script does one thing. If you double-click the title bar without moving the mouse, the script does something else. If you double-click the title bar while moving the mouse, the script performs a third action. (The second click does not have to be on the title bar.)
  10. Using <RCTRL><SHIFT>character could give you in a more reliable script than one that clicks on an icon. It's not like mouse manipulation macros cannot be made reliable; but it is harder!
  11. Insert a "Wait for Window Title" command at the end of the loop, so the script might look something like this: <WAIT FOR WINDOW TITLE Title="Task is done!" Partial="FALSE" Wildcards="FALSE" Indefinite="FALSE" Hours="0" Minutes="0" Seconds="300"/> <TEXT TYPE Action="0" Text="<ENTER>"/> You would need to set the title of the message box; I am assuming here that it is "Task is done!" The second line presses the Enter key, which in your case, may or may not activate the OK button. You will need to modify to make it work!
  12. The answer is maybe. If there is a way, either indirectly or directly, to infer when a loop is done, you may be able to script it via Macro Express. Things that you can look for as clues include: 1. The mouse cursor briefly changes shape when the process is complete. 2. Some object in the user interface changes colour when the process is complete. 3. Text appears in a field when the process is complete. 4. The text in a control changes when the process is complete. If you provide more information about what happens when a loop is done, even if it is extremely subtle, write back, and hopefully the collective wisdom of this forum will be able to give you more ideas! As an example, if text appears in an empty field to indicate the loop is done, you might be able to do something like this: clear the clipboard, move the cursor to the field, and then, every 5 seconds for 300 seconds, select the field and copy it to the clipboard. Test if the length of the clipboard text is greater than zero. If it is, then the field has been populated, and you are done. Otherwise, repeat 5 seconds later.
  13. The most likely reason I can think of is that you specified a capital letter where you need lower case. Let's say the hotkey is Ctrl + Shift + T. Instead of this: <CONTROL><SHIFT>T Try this: <CONTROL><SHIFT>t
  14. What have you set the activation to start ME3? I believe the default hotkey is Ctrl + Alt + Shift + W, but if you changed it to something else, perhaps you pressed it? Do you have an ME3 icon on your desktop? If yes, check its properties; you may have inadvertently set the "shortcut key" to something easy to press by accident.
  15. I am continuing my experiments with control-based scripts, and finding that sometimes a hybrid approach works best. In some contexts, sending keystrokes yields more reliable scripts. But I am enjoying not having to rely on the clipboard to capture control text when there are MEP commands that copy text directly to variables. Thank you Cory for the reminder that MEP has this functionality built in. Now, I have two versions of the same macro -- a script to simplify command development in NaturallySpeaking. One macro sends keystrokes, the other manipulates controls. The latter runs faster, and has 25% fewer lines of code. The learning curve has been steep, but it's been worth the effort.
  16. Thank you, Cory, for your thoughts. I find that manipulating controls can result in elegant solutions, but the learning curve is long, the coding tends to be more complex, and the need to write clear comments is greater. I will press on with controls…
  17. When there are two way to move the cursor to a control, by sending a sequence of keys or capturing controls, how do you decide which is the best approach? For example, I am writing scripts for an application that extracts information from a field. I can do this in two ways: Type <Alt><x> (move to the ABC field) Type <Ctrl><a> (select the ABC field) Type <Ctrl>c (copy the field) or Get Control ABC Set Focus ABC Type <Ctrl><a> (select the ABC field) Type <Ctrl>c (copy the field) The first approach is easier to implement but less reliable. For example, all hell can break lose if another window intrudes while the script is running. The second approach should be more reliable, but is a more complex to implement. I thought that this approach might run faster, but I find that it may run slower. I guess it's faster to send keystrokes than to collect and manipulate control information. How do you decide the best approach to capturing this kind of information when both alternatives can be made to work?
  18. I am thinking out loud, have never tried anything like this.... Use macros triggered by Events (System Events: Resolution Change? Incoming Message? but more likely Process Event) to monitor when processos are launched and closed. Control events might work, although I foresee complications... On closing a process, check the screen resolution, and save one (or both? results as an integer variable into either into the registry, or a file. When opening, check the previously saved screen resolution value or values. If they match, you are on the same monitor, so move window to this monitor. Else move it to the other.
  19. And here in (English-speaking) Canada, our keyboards are more like the Australian than the English. The photo LOOKS like this keyboard might have the "Gr Alt" key, which changes some how some characters are accessed. See: http://en.wikipedia.org/wiki/AltGr_key I guess the main way to tell is this: does your keyboard have two "Alt" keys, or one "Alt" and a "Gr Alt" key? If the former, it should work; if the latter, you might have to hold down "Gr Alt" while pressing the key. (I think Shift is involved somehow too...) Maybe it would work if you change the keymapping for Windows from UK English to -- may I say it? -- US English?
  20. Two things to try: 1. Change the way you capture the control. If you are capturing text, uncheck the option. And vice versa. 2. Insert a short time delay before the Set Focus statement.
  21. Hi Terry, Google has been my homepage for so long – 12 or 13 years! – that I went on the assumption that the same is true for everybody. Probably not a good assumption… The code that I posted only works if you have set Google as your homepage. (Also, I am using Firefox as my default browser, which may not be true for everybody.)
  22. With this command, I have discovered no consistency with opening windows and gaining focus. In some context one works, and sometimes the other.
  23. Variable Set String %Clipboard% from the clipboard contents Variable Modify String %Clipboard%: Trim Launch Program and Activate Window: Program "FIREFOX.EXE", Parameters ""%Clipboard%"", Window "- Mozilla Firefox" The second line isn't really necessary, but it should make the macro a little more reliable by stripping away leading and trailing spaces.
  24. Just for fun, I wrote the (clunky) script for the benefit of those who don't know VBA. Text Type (Simulate Keystrokes): <CONTROL>1 Wait for Window Title: Format Cells Text Type (Simulate Keystrokes): n Text Type (Simulate Keystrokes): <ARROW RIGHT><ARROW RIGHT> Text Type (Simulate Keystrokes): <ALT>c Text Type (Simulate Keystrokes): <HOME> // Start colour picker // The next line of code moves focus to the desired colour swatch. Modify as needed. // In Excel 2007, <ARROW DOWN> moves focus to a shade of red. // Add other arrow key commands to select a different colour. Text Type (Simulate Keystrokes): <ARROW DOWN> // End colour picker Text Type (Simulate Keystrokes): <ENTER> Text Type (Simulate Keystrokes): <TAB> Text Type (Simulate Keystrokes): <ENTER>
×
×
  • Create New...