timing, default delays, and Wait for Text Playback

[margaret]

Do I need the default delays that are shown in Preferences if I use the "Wait for Text Playback" command after any Text Type command that is sending more than a couple of characters to an application? In the Preferences I see a default delay of 250 milliseconds after clipboard commands, and Text Type default delay of 300 milliseconds. My macro has Keystroke Speed set to 2 milliseconds. Some of the macros seem a little slow in pasting, and I was just wondering about these default delays versus Wait for Text Playback. (The macros copy, then switch to another application and paste in, and they do a varying amount of handling to the text before pasting in depending on which macro, and they are sometimes a little unpredictable. I've just discovered Wait for Text Playback, which seems to make them more reliable.)

 

Thanks,

 

Meg

[rberq]

I think the Preferences for keystrokes is 300 microseconds, not milliseconds. That's not much time, but I think you can leave it at the default if you set Keystroke Speed in your macros. I have had to set Keystroke Speed AND Mouse Speed in many macros -- 30ms seems to work pretty well, though some applications are happy with much lower values. Like you, I have found that Wait for Text Playback makes the macros more reliable, though it is kind of slow! Wait Text Playback will not always compensate for a too-fast Keystroke Speed. If you are typing a long string of data, and keystrokes are delivered very fast by ME, then the Windows or application keyboard buffer can be overflowed because characters are coming in faster than Windows can handle them.

[margaret]

I think the Preferences for keystrokes is 300 microseconds, not milliseconds. That's not much time, but I think you can leave it at the default if you set Keystroke Speed in your macros. I have had to set Keystroke Speed AND Mouse Speed in many macros --...

 

I looked at that dialog again. The default for clipboard commands is expressed in milliseconds but the Text Type delay is microseconds (300 microseconds = .3 milliseconds I guess). OK, that's a lot less time than I was thinking. In most cases in my macros, text is not being typed in. It is being pasted in from a variable -- originally text is copied to the clipboard, then the macro evaluates the string and trims off extra spaces, etc., and in some cases manipulates it further, then from the resulting variable, the text is pasted in. (Or should Wait for Text Playback not apply when it's one paste rather than a number of keystrokes??) In the few cases where the user is typing something in, speed shouldn't be a problem because in those cases the macro has to wait until the user presses Enter before it continues. I might not need all the delays I currently have now that I have this Wait Text Playback. I'll do some more experimenting. It's the time to allow for switching windows that seems to vary the most from one program to another.

 

Thanks!

 

Meg

[Yehnfikm8Gq]

.....Or should Wait for Text Playback not apply when it's one paste rather than a number of keystrokes??)

 

According to the ME Bible, Wait for Text Playback only applies to Text commands. Moderate amount of paste really need a time delay. When I'm moving 400KB of text from a web page it may need several seconds each to be sure of the Copy and the Paste. Otherwise 300mS and down to 10mS should suffice. It may be that copying text off or on to documents that contain other items such as images takes longer. PC setup may significantly affect times.

 

Something else I've found is that it can help to have a very short time delay (10mS?) after the Wait for (Anything) commands. It seems like the Wait for command hasn't quite done with the processor when it gives the OK signal. That could be PC specific.

[margaret]

According to the ME Bible, Wait for Text Playback only applies to Text commands. Moderate amount of paste really need a time delay. When I'm moving 400KB of text from a web page it may need several seconds each to be sure of the Copy and the Paste. Otherwise 300mS and down to 10mS should suffice. It may be that copying text off or on to documents that contain other items such as images takes longer. PC setup may significantly affect times.

 

Something else I've found is that it can help to have a very short time delay (10mS?) after the Wait for (Anything) commands. It seems like the Wait for command hasn't quite done with the processor when it gives the OK signal. That could be PC specific.

 

But it is a Text command -- like Text Type: %10% for example -- with %10% being the modified variable. I can't do an actual paste or I wouldn't be able to modify the string in between the copy and paste. Unless I can essentially put the modified variable into the clipboard? Would that be better? We're never talking about a large amount of text -- let's say under 10 words each time, not whole sentences even, often just one word or a few words. No images at all in the receiving application; there may be images in the file that's being copied from, but those images would never be copied.

[Yehnfikm8Gq]

But it is a Text command -- like Text Type: %10% for example -- with %10% being the modified variable.....

 

Text Type is a Text command. Paste could be handling anything although for most purposes would be alphanumeric. Unless someone can offer opinion to the contrary, Paste is emptying the clipboard in one blob and does not count as a Text command. It makes no attempt to provide output until it has finished processing the data.

 

When I have URLs typed in a browser, they are quite long and type in spurts at relatively slow speed. I usually use Wait for Text Playback and add a short delay at the end. Way back, I think I tried to Paste but found that typing the text was more reliable with the Wait for.. command. Text Type is not great with large quantities of text.

 

I've never had to bother modifying keystroke speeds. Whatever the default is, that's it. As with much of ME application, it's finding what works best for your setup. If I have problems with commands, the first thing I usually do is add a delay after and see if it works. Even the shortest delay can make quite a difference. The extra command seems to get things in order, out of proportion to its apparent significance.

 

If I want to modify a variable between Copy and Paste I always use a Variable. I've never thought of doing it any other way. Is there? I may choose to Text Type if the end application prefers that per browser mentioned above.

 

As an aside from an earlier thread on copying filenames from Explorer to the Clipboard, the Clipboard does its best to handle a wide variety of data but what comes out is not necessarily what you think. Text should be fine. Even that may need to be processed from (say) formatted Word to unformatted text.

[rberq]

Unless I can essentially put the modified variable into the clipboard? Would that be better?

You CAN put the modified variable into the clipboard: VARIABLE MODIFY STRING/SAVE TO CLIPBOARD (it's on the second tab).

But I have had little success with pasting from the clipboard, regardless whether I use the CLIPBOARD PASTE command (which says it issues Ctrl-v), or the clipboard-paste option of the TEXT TYPE command, or by directly typing Ctrl-v. It works sometimes in some applications on some PCs, but not reliably everywhere.

[Yehnfikm8Gq]

I've found Paste is reliable if you allow enough time and the application doesn't mind Paste. It's the only option with large quantities of text. In some of my old macros where I needed reliability in the shortest possible time I counted the number of characters and proportioned the time delay for Copy and Paste accordingly. That was with widely varying amounts of text to be copied. I vaguely remember 60,000 characters per sec for my old PC. You have to balance time for counting against time saved in the Copy and Paste. If you are doing it from the content of a text file or similar such as html you could probably evaluate far quicker from the file size.

 

Although I described it as dumping the Clipboard in a blob, in reality the content is pasted sequentially. Any interruption can lead to the dump being truncated. I can't understand why that occurs. Windows is given the task of pasting and should not allow anything to interrupt. If another window tries to come to the top, it should be prevented from doing so until the previous tasks are done or the pasting should continue on the now-lower window. Instead it's "Insert Time Delay Here".