rberq

Generally, yes, same logic.  Except you will need to extract more than just one digit from the end of the URL. 

There may well be better ways to get at the URL, but I don't know them.

I have had mixed success with WAIT FOR WEB PAGE.  I seem to recall that it is intended to work only with Internet Explorer.  I have one macro where it works very well in Firefox, but others where I have to check colors at key positions of the screen to decide whether the page has finished loading. 

Well, I see acantor and I have been working in parallel, so this is kind of a repeat.  Here's the macro I just tested.  It is sloppy and slow because it relies on opening and closing Notepad on the screen.  Maybe you can figure out a way to streamline it.  

Here is something that seems to work, because Notepad seems to handle your funny characters.  Assume you already have "file B" and you want to append some copied text.  Highlight the text, then trigger this macro.

Delete File/Files: "c:\temp9\filea.txt"                        // delete temporary work file A
Text Type (Simulate Keystrokes): <CTRLD>c<CTRLU>               // copy text to clipboard
Delay: 100 milliseconds
Program Launch: "notepad" (Normal)                             // start MS Notepad blank screen
Text Type (Simulate Keystrokes): <CTRLD>v<CTRLU>               // paste text into Notepad      
Text Type (Simulate Keystrokes): <ALTD>f<ALTU>a                // save Notepad as file A
Text Type (Simulate Keystrokes): c:\temp9\filea.txt
Text Type (Simulate Keystrokes): <ENTER>
Text Type (Simulate Keystrokes): <ALTD>f<ALTU>x                // close Notepad
Program Launch: "filecopy.bat" (Normal)                        // append file A from Notepad, to pre-existing file B
Macro Return

Batch file "filecopy.bat", launched by the macro, consists of the old-fashioned DOS command
Copy c:\temp9\fileb.txt +  c:\temp9\filea.txt  c:\temp9\fileb.txt

Do a forum search for "Unicode".  Maybe you will find something helpful.  Probably not.😞

You can bold the selected cell in Excel by typing Ctrl-b.
In a macro, the command would be
Text Type (Simulate Keystrokes): <CTRLD>b<CTRLU>

However, in my version of Excel, bolding a cell clears the value in the clipboard.  So bold it BEFORE you copy it to the clipboard, not after. 

I tested with my old ME 3 version.  Same high CPU.  Windows Task Manager shows ME running as a App, and again as a Background Process.  The high CPU is reported for the Background process, not for the App.  So that's three versions of ME we have seen with the same high CPU -- ME 3 -- ME Pro 4.9 -- ME Pro 6.   

My version of ME is 4.9.  I don't know why you can't run multiple macros simultaneously -- unless you are using the "lock player" command???

Yes.  If I Delay for 30 seconds, it eats 25% of the CPU.  If I Delay in two macros running concurrently, it eats 50%.

However, if I use the "Timed Delay" option, I see no increase in CPU usage. 

I assume "Timed Delay" sets an operating system interrupt to "Wake me in 30 seconds", where "Delay" probably is a CPU-intensive loop within ME itself.  As advertised, the Delay macro can be cancelled at any time, but Timed Delay can't easily be cancelled until the time expires. 

28 minutes ago, Cory said:

learn things like when to use the control and when to use control up/down combination (almost never).

It is audacious to disagree with Cory, but I recommend almost always to use the control down/up combination.  So you could change your macro script

from <CTRL>s to <CTRLD>s<CTRLU>.  I seem to be the only person who has trouble with one version vs. the other, but maybe you have joined me. 

I have had the problem, occasionally, of the CTRL key remaining "stuck" down, but only when a macro has been aborted before its normal end.  You could try adding an extra Text Type of <CTRLU> and see if that helps.  I tested using extra <CTRLU> commands when they are not needed, and it seems to cause no problem. 

I'm not familiar with the iCue variable delay, but this is the Delay command in Macro Express.  Notice that you can explicitly code the duration of the delay, or you can specify the duration in a variable.  The variable can have an expllcit value as well, or you can set it to a random value.

1 hour ago, acantor said:

I thought of another workaround. It also involves two macros:

Clever, and it should run really fast.  I should keep looking for opportunities to use controls, so I can learn more about them.  I always forget to consider them when coding macros. 

Would it work, to change the last line of your macro (Text Type (Simulate Keystrokes): <TAB><SPACE>) to find and set focus to the OK button and click on the control?

(Yeah, I know, I should take this opportunity to learn by figuring it out for myself -- but lunch calls.😋)

1 hour ago, stevecasper said:

rather than track down every macro I have that uses a variable prompt and add in this extra Macro Run command.

Hmmm...  That is the problem.  You do NOT NOT NOT want a Macro Run command to execute acantor's macro or my variation on his macro.   Re-read acantor's suggestion.  The "fix" macro is triggered automatically by the appearance of the PROMPT window, named "Enter String Value" (exact match).  You specify that in the Activations tab of the script editor. 

I have a macro similar to what acantor suggested.  Try changing it as shown below.

Wait for Key Press: ENTER
Text Type (Simulate Keystrokes): <TAB>
Delay: 250 milliseconds // delay so ENTER will not happen until tab selection happens
Text Type (Simulate Keystrokes): <ENTER>

No guarantees -- but the delay fixed my problem with a multiple-choice menu.  Since this short macro is interacting (indirectly, via the "keyboard") with the PROMPT macro, the TAB and ENTER keystrokes may need to be separated slightly in time, so the PROMPT macro has time to respond. 

Without disagreeing with what Cory and acantor said ... your macro appears to be moving the mouse rightward and upward, rather than rightward and downward.

The x coordinate is horizontal, and x increases from left to right.

The y coordinate is vertical, and y increases from top to bottom. 

Also be careful whether you specify movements as relative to screen, relative to window, or relative to the current mouse position -- it's an option in the Move Mouse command. 

It can be slow, but I have a couple macros that move the mouse down a column like that, looking for a color change, or (better) for the mouse cursor to change when it gets to a "clickable" location.  Then click the mouse, and repeat.  Usually the mouse can be moved more than one pixel at a time, which speeds things up -- depends on the granularity of the screen.  For your situation, it probably would be faster to move upwards from the bottom of the column, so the mouse wouldn't have to move downward over all that expanded detail space that opens up below each line.  If testing whether the mouse cursor has changed, the movement can't be too fast, or the mouse will move on before the cursor has time to change. 

Typing <CTRLD>f<CTRLU> works with several browsers to find text on a web page.  With Firefox, the macro must "type" ESC after the find, to exit from find mode.  

I have the same issue with my bank.  I think this macro does what you want.  It starts with a screen showing a few credit card transactions, then repeatedly expands the web page to show a longer list as long as there are more to show.  This works with Firefox, where typing a single-quote can be substituted for typing <CTRLD>a<CTRLU>.  

//  
Delay: 500 milliseconds
Text Type (Simulate Keystrokes): 'all transactions<ESC> // get focus on "All Transactions" button and press ENTER
Delay: 900 milliseconds
Text Type (Simulate Keystrokes): <ENTER>
//  
Repeat Start (Repeat 10 times) // Keep selecting "Show More" as long as it appears
  Delay: 900 milliseconds
  Mouse Move: 800, 400 Relative to Screen // Click within screen
  Mouse Left Click
  Delay: 100 milliseconds
  Text Type (Simulate Keystrokes): <CTRLD>a<CTRLU> // Highlight all and copy screen contents to clipboard
  Delay: 100 milliseconds
  Macro Run: Kybd_Copy_to_Clipboard_All
  Delay: 100 milliseconds
  Mouse Move: 800, 400 Relative to Screen // Click within screen again to cancel highlighting
  Mouse Left Click
  If Clipboard Contains "show more" // If "Show More" button exists, activate it, otherwise exit from repeat loop
    Text Type (Simulate Keystrokes): 'show more
    Text Type (Simulate Keystrokes): <ESC>
    Text Type (Simulate Keystrokes): <ENTER>
  Else
    Text Type (Simulate Keystrokes): <CTRLD><HOME><CTRLU> // Go to top
    Delay: 250 milliseconds
    Mouse Move: 800, 510 Relative to Screen // Click within screen to clear remaining highlighting
    Mouse Left Click
    Repeat Exit
  End If
End Repeat
//  
Macro Return
//  

A couple wild guesses:

1) Do you have a "reasonable" keystroke speed set in your macro?  I generally use "Keystroke Speed: 30 milliseconds" in any macro that does typing, at least initially; then later I may speed up or slow down the typing if necessary.  I think Excel or Windows will buffer the keystrokes if the macro types them too fast, but that has its limitations if the buffer fills up.

2) Are you sure the Excel window has focus when the macro begins typing?  I have a couple macros that "Wait for mouse click" before they begin to type.  That way, I manually click on the first cell the macro will type into, so both the Excel sheet and the proper cell are active when typing begins. 
 

Is the FTP transfer preceded by FTP log-on, FTP change directory, and so on?  Does the logging indicate success of those commands?

I don't recall that I ever got Macro Express to work reliably for FTP.  Instead, I would build a DOS-style command-line file containing all the FTP commands, and have the macro run the .BAT file (Program Launch).  For a "static" situation, the command-line file can be built ahead of time and re-used every time the macro runs.  For more complicated situations -- a different file name every day, for example -- I would have the macro build the entire .BAT file and then launch the file it had just built.  This worked very reliably.  I backed up hundreds of files per day by having the macro dynamically build hundreds of individual .BAT files and then launch them.

I have the abort hotkey set up as shown on the attached image.  I use a macro to type the hotkey combination, because it is easier than contorting my hand to type it, if in a panic situation I could even remember what to type.  The abort macro (below) is triggered by Keypad-1, which is easier and quicker for me to type.  

I don't remember why my macro repeats the abort hotkey multiple times -- I must have found that once didn't always do the job.  

This has been pretty reliable for killing runaway macros.  I think the only time a macro excapes cancellation, is when that macro is temporarily in a "Delay ... without ability to halt".  Come to think of it, maybe that's why I repeated the abort -- so as to catch macros when they were NOT in that delay.  

//  
Text Box Display: Information // Message that running macros are being aborted
Delay: 1000 milliseconds
Text Box Close: Information
// Repeat abort sequence until this macro itself is aborted
// Keystrokes defined in Macro Express Options | Preferences to abort macros
Repeat Start (Repeat 100 times)
  Text Type (Simulate Keystrokes): <WIN>`  // Type WIN key with left quote
  Delay: 100 milliseconds
End Repeat
//  
Macro Return
//  

If the macro is working with network files -- not on the PC itself -- then a slow internet connection certainly could cause problems. 

Since the problem is intermittent, based on your description I wonder if focus is being lost temporarily from the screen that the macro is working with.  This would potentially cause keystrokes to be "lost" -- that is, typed into some other application that has no use for them.  Once the macro gets out of sync with the application screen, random strange things will happen.  If you can pinpoint a specific spot where things go wrong, you could add macro instructions to check window focus at strategic times.  I have seen cases where an unexpected window "appeared" and disappeared so fast it never was visible to the user, but triggered some unrelated macro to run and caused major disruption. 

The same kind of problems could result from too-fast keystrokes outrunning the application. 

A technique I have used is to write log messages documenting the progress of the macro.  Then after a failure you can review the log and see where the proper sequence ended.  To reduce logging overhead, you could have another macro set some kind of switch (referenced by the problem macro) that turns logging on and off.

7 hours ago, acantor said:

but my recollection is that the scripts sometimes failed to trigger at the appointed times. But Macro Express has come a long way since then.

I'm not sure the scheduling has come a long way.  I have a couple alerts:

The first one is scheduled much like terrypin's, to run at 18:30 Monday through Friday.  Once in a great while it does run at 18:30, but usually it just runs when Windows wakes up from sleeping, regardless of time of day.  However, wondering and watching for whether it will run or not is kind of a reminder in itself, so I guess it's not a total failure.😋

The second alert is very reliable, but only because the macro is scheduled for every 5 minutes and does its own date and time checking and either alerts or not depending on what it finds.  In fact, it should run any second now -- yep, there it goes, just like Old Faithful. 

I followed your path of using ME to automate a lot of repetitive functions in my regular job, which was operating-system-management / maintenance / application design / programming of large IBM systems.  I always said ME was worth half a person in time savings.  You discovered the same in your job.  

Later I used ME to automate repetitive functions for about 350 other users.  MISTAKE!!!  Managers of those users wanted what you describe as "the polish of a professional program" -- they wanted Macro Express to protect against stupid and to substitute for the users' really knowing how their applications interacted in "vanilla" mode (without macros).  Though the macros performed well 99.9 percent of the time, that last 1/10 percent was a constant headache.  

So it is easy to over-reach the capabilities and strengths of Macro Express.  In an ideal world, you might find a job where you could develop macros for sophisticated users, to ease and speed them along as you eased and speeded yourself.  If you do, don't think of it as a forever job -- use it as an opportunity to train yourself and move into other computer jobs you see around you in your company.  You will eventually need more tools and skills to remain relevant, so always be learning new stuff. 

That's the way my 4.9 version works, and that's the way my 3.7 version works.  The Help screens are a little vague -- see below -- but apparently Keep Focus is only for the initial display.  I suppose it would be nice to have another option -- either "Initial Focus" or "Really and Truly Always Focus".

29 minutes ago, acantor said:

You can test Caps Lock state in Version 6. For example:

Oops!  Turns out you can do this in version 4.9 also.  Forget my previous advice.

You could make a second macro, activated by a hot key, that sets/clears a flag for pause/go.

Your main macro could check the flag and delay, or not.  Checking the flag could be as frequently as you want, and the delays could be short or long, depending on how responsive you need it to be.

The flag you set could be a registry value, the existence or non-existence of a file, etc.

4 hours ago, ihuxihy said:

That's a funny yet sad way, but I guess it will work, thank you.

I think of it as cute, not sad.😋  It is not an ideal solution, and you have to watch the timings, and consider what other applications might be running, and what other mouse clicking might be going on.  But if you have a relatively stand-alone application, and a user who won't get flustered if the "wait" times out, it should work OK.