rberq

Yes. It sounds like you have competent and knowledgeable users. So you can break down your procedure and give them macros wherever macros can help. My biggest problem with processes like this was when a manager would say, "My people don't really understand what is going on, just make the computer do everything from beginning to end so they can't mess it up." 🫢

Here are a couple initial thoughts: 1) Drive the Repeat loop via a file, using Text File Begin Process or ASCII File Begin Process. Get the dates into the file by any of the methods you have described; or by entering them into a spreadsheet and exporting that (with your macro) to a TXT or CSV file; or just by using something like Notepad. Then visually review the list of dates and start your macro to process them. Using a file has the benefit of flexibility, where the set of dates can be very small or very large depending on the user's time availability. Think about how you will control the process -- that is, how will you keep track of which file(s) of dates have been completed, which are pending, and so on. Have the macro produce a text file log of each date successfully processed. 2) It sounds like your primary goal is to save on user idle time. That is, type a date then sit there idle for 30 seconds while the macro fills in a series of screens. Then repeat until the user falls asleep from boredom, all while there are other important things he/she could be doing. But is the screen-filling process so reliable and trouble-free that it can run for 5 or 10 or 30 minutes without ANY failures that put the screens out of sync with the list of dates? How often, now, does the user catch a problem with the screens and have to take corrective action?

I don't understand your reference to AHK, but I am going to assume you are controlling the POS terminal with a Windows application. You could have a macro that runs continuously, waiting for a mouse click. When a mouse click occurs, get mouse position and get pixel color under mouse. If appropriate area of the screen, and appropriate color, print -- but I'm not sure how to direct printing to the receipt. Back to waiting for mouse click. In pseudo-code: REPEAT START WAIT FOR LEFT MOUSE CLICK GET MOUSE POSITION INTO INTEGER_X, INTEGER_Y GET PIXEL COLOR UNDER MOUSE INTO INTEGER_COLOR IF MOUSE WITHIN RANGE AND IF INTEGER_COLOR = 1234567 TEXT TYPE "VOID" (I'm not sure where this will go -- usually "TYPE" goes wherever the cursor is) END IF REPEAT END

Looks pretty elegant to me.

If you export the spreadsheet to a tab-delimited-txt file, or to a comma-delimited-csv, per Cory's suggestion, then the ASCII File Begin Process command can split the string for you. Or, per acantor's method, it's not too hard to write a Repeat loop that does the same thing as the Split String command.

Aha!!! Because my bank's web site was annoying me, and for the irony, I wrote a robot (macro) to click the box verifying that "I am not a robot." And yes, after a while the macro stopped working. I never could figure out why, so thank you for the explanation. 😇

Samrae's suggestion is excellent, but the IF / END IF section should perhaps be enclosed in a REPEAT loop. Another idea you might combine with that, is to use keystrokes to highlight the entire spreadsheet row, do a single Clipboard Copy of the entire row, then parse the captured cells into individual variables. That might be a bit faster and more reliable than copying individual cells to the clipboard, but you would still be wise to include Samrae's technique for the single copy command. Incidentally, I have long used a separate macro called "Generic Copy to Clipboard" that I call from many other macros, and my generic copy uses a variation of Samrae's method. The advantage of this technique is that the ME "Preferences" for a wait after clipboard commands can be set to zero. A question in my mind was whether the clipboard might not be empty, but might be only partway filled. In other words, might the macro timing be such that the clipboard contains (for example) only the first 4,000 bytes of 7,000 that eventually will be copied -- so the macro "thinks" it is done when it still needs more time. In a word, this has never happened even during stress testing. The clipboard copy is always all or nothing. (But I suppose that Microsoft could "fix" this in a future release.😄)

Originally you said, “the mouse move may not work SOMETIMES.” In your last post you said, “Button is NEVER in same spot.” I’m not trying to be picky – which is correct??? I have a few web pages where the button moves but only to a few predictable spots. So I just click on them all because clicking the wrong spot doesn’t hurt anything. Or I check pixels at each of the few possible locations and click the one that matches. This may not be applicable in your situation, but worth investigating.

One suggestion in addition to all the above -- Sometimes a web page, on the screen, is really more than one page. (Or at least seems to be -- I'm not sure what is really happening under the covers.) Before doing the Ctrl-f search, try clicking the mouse (once) somewhere in the vicinity of where you hope to find the word. That will bring the right section of the screen into focus so the Ctrl-f will be operating on the proper area. I generally have the macro click at the extreme left or right or top or bottom, so it won't accidentally hit a button and go off to never-never land. You can easily test this on your particular web site by manually doing the mouse click and Ctrl-f.

Try using the Variable Set String command, with the option to Prompt for Value. See screen shot below.

OK, then revise my design by eliminating 99.9 percent of it. If the user can press hotkeys, and move the mouse, then the mouse button presses and releases and clicks can be done by simple macros. If the user can NOT press hotkeys, can Dragon activate the keys that then activate the macros? I don't see where the problem is -- it's awkward for the user, but doable with minimal macros. What am I missing?

I have a macro that zooms Firefox screens, to make the text bigger. The macro runs all the time Firefox is active. It checks the mouse position once every second. If I move the mouse to the extreme left margin of the screen, the macro types the Firefox key sequence to zoom in. The longer the mouse stays at the extreme left, the more times the zoom-in happens. If I move to the extreme right, it types the sequence to zoom to actual size. If the mouse is at extreme right, but has not moved since the previous observation, then zoom to actual size is not done, since it was already done previously. To take one of your scenarios – moving a block of text within a document – I would try something similar. (Design below is based on Microsoft Word.) 1) Mouse monitor macro running all the time, but takes no part in what follows except activating another macro. 2) Mouse monitor activates the block-move macro based on user moving mouse to extreme left in top half of screen. (Bottom half of screen, and top/bottom halves at extreme right reserved for the other three scenarios.) 3) Block-move macro does its own monitoring of mouse position, probably once every second. 4) User moves mouse to first character of text block to be moved, and holds position. Macro detects zero mouse movement for two seconds, presses left mouse button, flashes text box on screen briefly to inform user. (Text box may not be needed if user watches for cursor to change as a result of mouse button being pressed.) 5) Block-move macro continues to monitor mouse position every second. 6) User moves mouse to end of text block to be moved, and holds position. Macro detects zero mouse movement for two seconds, releases left mouse button, flashes text box on screen briefly to inform user. At this point the text block has been highlighted. 7) User moves mouse to middle of highlighted text block, holds position as before. Macro presses left button, user drags block to target position. After two seconds of no movement, macro releases left mouse position. Text block should now be in its new position. Well, that’s the general idea. Some refinements would no doubt be needed. For example, it is often difficult for me to hold the mouse totally still, so a few pixel’s of tolerance might be built in. I think some variations would work for the other three scenarios. Macros would be very much tailored to the specific scenario. You didn’t mention whether the user could use the keyboard in any way, so I assumed he could not. All the above would be more reliable, and easier to code, if the user had some other way (keystrokes) to signal pressing/releasing the mouse buttons. If no keyboard allowed, then perhaps no mouse movement for two seconds, followed by very rapid movement in one direction or another to signal which button function the macro will activate. That would require high-CPU monitoring of mouse position, not just once per second. I have written a couple macros that do that sort of mouse tracking, but then it’s a (not too difficult) matter of the user learning to move at the correct speed.

At this point, there is little reason to move your question to another forum section. Your macro is technically "clean" and it runs, but apparently doesn't do quite what you want. I don't recall just how "DATE/TIME" works in version 3 of Macro Express; but I suspect the screen shot of the script that you provided is not showing us the details of what is being stored in T1 and T2 and T99. The format being stored is HH:mm, but is that current time, or a time you specify, or what?

You have greater than 1000 milliseconds in total delays, so hh:mm:ss should never "miss the timing" as it goes through the Repeat loop subsequent times. Look to the overall logic of the macro, which others have commented on.

As my father used to remind me: "Use your head for something besides keeping your ears apart."