Clipboard Copy command doesn't get along with a certain applicaton?

[margaret]

If the Clipboard Copy command doesn't work in a certain application, even though it has worked perfectly in similar programs in many macros, what should I suspect? Copying with keyboard shortcuts in that application seems to work fine.

Thanks.

[rberq]

If the copy works via manual keystrokes, and you are duplicating those keystrokes in your macro, then I would suspect a timing issue. Are you familiar with Options | Preferences | Delays | Delay After Clipboard Commands? That option is there because Windows apparently does not complete clipboard functions in a reliable time-frame. Setting a delay allows "most" clipboard functions to complete properly.

 

The problem is, completing "most" clipboard actions properly is not adequate for a production application. Setting a high-enough delay makes it almost fail-safe, but can make the application unpleasantly slow for users. Because of that problem, and based on suggestions in this forum, I never do a simple Clipboard Copy. Rather, I set the ME delay to zero, and call a simple macro that issues the Clipboard Copy, then loops every 20 milliseconds checking for non-nulls in the clipboard. If after 50 loops (about a second) the clipboard is still null, the macro exits making the assumption that the actual data to be copied was null. The excessive delay experienced by users then occurs only for null fields. So far this technique seems to be 99.99999 percent successful -- that is, I have seen no failures, but never say never ....

[terrypin]

If the copy works via manual keystrokes, and you are duplicating those keystrokes in your macro, then I would suspect a timing issue. Are you familiar with Options | Preferences | Delays | Delay After Clipboard Commands? That option is there because Windows apparently does not complete clipboard functions in a reliable time-frame. Setting a delay allows "most" clipboard functions to complete properly.

 

The problem is, completing "most" clipboard actions properly is not adequate for a production application. Setting a high-enough delay makes it almost fail-safe, but can make the application unpleasantly slow for users. Because of that problem, and based on suggestions in this forum, I never do a simple Clipboard Copy. Rather, I set the ME delay to zero, and call a simple macro that issues the Clipboard Copy, then loops every 20 milliseconds checking for non-nulls in the clipboard. If after 50 loops (about a second) the clipboard is still null, the macro exits making the assumption that the actual data to be copied was null. The excessive delay experienced by users then occurs only for null fields. So far this technique seems to be 99.99999 percent successful -- that is, I have seen no failures, but never say never ....

 

Bob,

 

Interesting approach, must try it. I've got into the (possibly bad?) habit of using plain Text Type:

Keystroke Speed: 10 milliseconds

// Etc

Text Type (Simulate Keystrokes): <CONTROL>c

Wait for Text Playback // Recently changed. Previously I've been using a 100 ms Delay

// Etc

And at present I have Options > Preferences > Playback > Delays set to 2000 microsecs, 250 ms, 250 ms respectively.

 

Presumably your subroutine empties the clipboard before each copy?

 

--

Terry, East Grinstead, UK

[randallf]

Hello everyone, have you tried:

 

Repeat Until %T1% <> ""

Clipboard Empty

Clipboard Copy

Variable Set String %T1% from Clipboard

Repeat End

 

Seems like it should work almost anywhere, but who knows if you've tried it! Love to know what you think because the clipboard speed gets me, too. Thanks for helping me see it in a different way!

 

Here is what a lot of my stuff looks like because I am way too lazy:

Clipboard Copy

Delay 0.1 Seconds

 

[rberq]

Repeat Until %T1% <> ""

Clipboard Empty

Clipboard Copy

Variable Set String %T1% from Clipboard

Repeat End

 

terrypin: Yes, I do empty the clipboard before each copy. Good point!

 

Rand: Yes, that's pretty much the right approach, but the Repeat should be AFTER the Clipboard Empty and Copy so the Copy only happens once. I include a 20 ms delay inside the Repeat loop, more so that I can time bringing the loop to an end than for any other reason. Remember that, if the data being copied is null, your Repeat loop above will never end on its own....

 

Also, you can test the clipboard itself for null value, rather than take the extra time to move its value to T1. Finally, this whole approach relies on the fact that the Clipboard Empty command itself does not rely on a delay time, it just works, period!

[margaret]

Thanks to all who responded. (My ISP has been experimenting with different spam-trapping programs, so I didn't get the notifications until today.) I'm not using simulated keystrokes, just the Clipboard Copy command. I try to avoid using simulated keystrokes unless it's the only way. (My first attempts at writing these macros relied on simulating keystrokes and that was much less reliable than using MacEx commands -- especially for switching windows. I occasionally have to add a "wait for" some window to appear, but not always.) What's interesting is that I'm writing sets of similar macros that copy from various applications that all handle the same type of file. So far I've written sets that work with four different applications, and the Clipboard Copy was no problem whatsoever. All the testing is done in the same version of Windows. So I don't know if this new problem is really in that particular application, or perhaps in the way that particular application communicates with Windows. But I'll try testing for the existence of the variable and see if that works.

 

Meg

[margaret]

If the copy works via manual keystrokes, and you are duplicating those keystrokes in your macro, then I would suspect a timing issue. Are you familiar with Options | Preferences | Delays | Delay After Clipboard Commands? That option is there because Windows apparently does not complete clipboard functions in a reliable time-frame. Setting a delay allows "most" clipboard functions to complete properly.

 

The problem is, completing "most" clipboard actions properly is not adequate for a production application. Setting a high-enough delay makes it almost fail-safe, but can make the application unpleasantly slow for users. Because of that problem, and based on suggestions in this forum, I never do a simple Clipboard Copy. Rather, I set the ME delay to zero, and call a simple macro that issues the Clipboard Copy, then loops every 20 milliseconds checking for non-nulls in the clipboard. If after 50 loops (about a second) the clipboard is still null, the macro exits making the assumption that the actual data to be copied was null. The excessive delay experienced by users then occurs only for null fields. So far this technique seems to be 99.99999 percent successful -- that is, I have seen no failures, but never say never ....

 

Hi all,

Nothing else has worked except rberg's method above. With everything else I tried, even an improbably long delay just for testing, the variable never receives the text from the clipboard, even though the macro behaved as if it had (continued on to the next steps). But rberg's method of testing if Clipboard = "" then wait works. Thanks!

[paul]

Instead of

Clipboard Empty

which, in ME3, was always excruciatingly slow, I'd recommend

Variable Set String %T1% ""
Variable Modify String: Save %T1% to Clipboard

[rberq]

Paul, I believe you are the person who recommended this whole loop-until-it's-done technique in the first place. It has been a life-saver for me. Thanks.

[paul]

That's very good to know - I'll add "Life-saver" to my resume immediately <g>!

[rberq]

I tested with

Variable Set String %T1% ""

Variable Modify String: Save %T1% to Clipboard

instead of

Clipboard Empty

 

In a thousand repeats of the macro, it made no time difference. Maybe a different level of Windows makes the difference.

[paul]

Running 1000 times on a quad-core machine:

 

Clipboard Empty-------ME3: 4:21-----ME4: 2:49

Save "" to Clipboard---ME3: 0:00-----ME4: 0:00 (why are multiple spaces reduced to a to a single space - makes indenting very hard?)

 

The only probably difference between your environment and mine is that I am running Clipmate. However, the results of my macros remain pretty well constant, irrespective of whether Clipmate is enabled, disabled or unloaded!

[terrypin]

Running 1000 times on a quad-core machine:

 

Clipboard Empty-------ME3: 4:21-----ME4: 2:49

Save "" to Clipboard---ME3: 0:00-----ME4: 0:00 (why are multiple spaces reduced to a to a single space - makes indenting very hard?)

 

The only probably difference between your environment and mine is that I am running Clipmate. However, the results of my macros remain pretty well constant, irrespective of whether Clipmate is enabled, disabled or unloaded!

 

This is my second edit, around an hour after my first reply, as I've been doing further more methodical tests. With surprising results:

 

Clipboard empty 100 repeats

ME 3: 25.2 secs

<REP3:01:000001:000001:00100:0:01:><CLIPE><ENDREP>

 

ME Pro 24.8 secs

<REPEAT START Start="1" Step="1" Count="100" Save="FALSE" Variable="%N[1]%"/>
<CLIPBOARD EMPTY/>
<END REPEAT/>

 

Hardly any difference.

 

 

Alternative emptying method 100 repeats

ME 3: 1.4 secs

<REP3:01:000001:000001:00100:0:01:><TVAR2:01:01:><TMVAR2:16:01:00:000:000:><ENDREP>

 

 

ME Pro: 25.4 secs

<REPEAT START Start="1" Step="1" Count="100" Save="FALSE" Variable="%N[1]%"/>
<VARIABLE SET STRING Option="\x00" Destination="%X%"/>
<VARIABLE MODIFY STRING Option="\x10" Destination="%X%"/>
<END REPEAT/>
<SOUND FILE File="C:\\Docs\\Sounds\\Wave\\BAROQ2M0.WAV" Wait="FALSE" _PROMPT="0x0007" _ENABLED="FALSE"/>

Incredibly, about 20 times slower!

 

1 million repeats (99999 x 10)

ME3: 2.1 secs

<REM2:TEST 1:  1 million repeats, nothing inside loop><REP3:01:000001:000001:00010:0:01:><REP3:01:000001:000001:99999:0:01:><ENDREP><ENDREP>

 

ME Pro: 2.2 secs

<REPEAT START Start="1" Step="1" Count="10" Save="FALSE"/>
<REPEAT START Start="1" Step="1" Count="99999" Save="FALSE"/>
<END REPEAT/>
<END REPEAT/>

Hardly any difference.

 

 

1) What are those 0:00 times from Paul above?

 

2) This a Quad Core Q9450 2.66 GHz, 4 GB PC.

 

3) The alternative clipboard emptying method seems marginally slower in ME Pro here, not much faster as others have found. But how to explain why it's nearly 20 times slower than ME 3?

 

 

--

Terry, East Grinstead, UK

[stevecasper]

ME 3: 1.4 secs

<REP3:01:000001:000001:00100:0:01:><TVAR2:01:01:><TMVAR2:16:01:00:000:000:><ENDREP>

 

 

ME Pro: 25.4 secs

<REPEAT START Start="1" Step="1" Count="100" Save="FALSE" Variable="%N[1]%"/>
<VARIABLE SET STRING Option="\x00" Destination="%X%"/>
<VARIABLE MODIFY STRING Option="\x10" Destination="%X%"/>
<END REPEAT/>
<SOUND FILE File="C:\\Docs\\Sounds\\Wave\\BAROQ2M0.WAV" Wait="FALSE" _PROMPT="0x0007" _ENABLED="FALSE"/>

Incredibly, about 20 times slower!

I had very similar (even disconcerting) results.

 

In ME Pro I had slightly better times using Empty over T1="" -> Set T1 to Clipboard (27:45 sec / 100 vs 31:29 sec / 100)

 

However, in ME 3 my Empty time was about 26 sec / 100 whereas Set T1 to Clipboard was done so fast as to suggest it didn't repeat at all.

 

Tested on XP Professional, 512 RAM, 2 GHz Celeron.

 

Weird results. Pretty sure something wasn't right with the Repeat.

[paul]

1) What are those 0:00 times from Paul above?

Just that the excution of 1000 repeats was too fast to be measured.

[paul]

Well, today I'm getting entirely different results!!!

 

I'm using a Repeat 100 times.

 

I am now getting exactly the same 25 seconds as terrypin for saving an empty variable to the clipboard (whereas yesterday I was getting 0.0 seconds for 1000 repeats). ???

 

And this technique no longer clears the clipboard (don't forget I'm using Clipmate, so that may affect this statement - I'd be interested if this is the same for others).

[rberq]

Paul, how can you see that it is not clearing the clipboard? When I first started worrying about the clipboard, I would have ME do the CLIPBOARD EMPTY, then I would go to Microsoft Word and see that the MS Office clipboard still had 25 items stacked up and nothing had been cleared. Finally it dawned on me that Office was maintaining its own clipboard array, as opposed to the single level that Windows apparently has. Is Clipmate muddying the water like that?

 

It also wasn't clear to me whether a time delay applied to emptying the clipboard, or storing a null variable into it. So after the CLIPBOARD EMPTY, I included a little loop:

REPEAT START

IF CLIPBOARD = ""

REPEAT EXIT

END IF

REPEAT END

I don't think there IS a delay for the clipboard empty or for storing a variable into the clipboard or vice versa. I guess I could put a counter into the loop to find out.

 

As I said, the production version of my macro includes a similar loop AFTER the clipboard-copy command, delaying 20 milliseconds then checking for clipboard <> nulls, then repeat.... That loop does have a counter in it that gets written to the standard ME log just out of curiosity, so I can see how many 20 ms delays there are before the clipboard copy finally completes. Usually the count is 1, but it's not unusual to see counts of 3 or 4.

[terrypin]

Bob,

 

Do you also have ME Pro? If so, I'd be very interested in your timing for the extremely slow macro I posted up-thread, i.e:

 

<REPEAT START Start="1" Step="1" Count="100" Save="FALSE" Variable="%N[1]%"/>
<VARIABLE SET STRING Option="\x00" Destination="%X%"/>
<VARIABLE MODIFY STRING Option="\x10" Destination="%X%"/>
<END REPEAT/>

 

And anyone else, of course.

 

--

Terry, East Grinstead, UK

[rberq]

Sorry, no ME Pro yet.

[paul]

Paul, how can you see that it is not clearing the clipboard?

I use Clipmate and thus can see, at all times, exactly what is now in the clipboard and what has ever been in the clipboard (which I can reaccess at will). I also included code at the end of the test macro to retrieve the contents of the clipboard and display it.

 

Assume the contents of the clipboard are "Abc".

In Me3, writing an empty string to the clipboard results in "Abc" disappearing from view; but note no new value has been added to the clipboard - it's merely empty.

In Me4, nothing happens - "Abc" remains visible and retrievable.

[rberq]

Can you turn off / disable Clipmate and test it that way?

[terrypin]

I use Clipmate and thus can see, at all times, exactly what is now in the clipboard and what has ever been in the clipboard (which I can reaccess at will). I also included code at the end of the test macro to retrieve the contents of the clipboard and display it.

 

Assume the contents of the clipboard are "Abc".

In Me3, writing an empty string to the clipboard results in "Abc" disappearing from view; but note no new value has been added to the clipboard - it's merely empty.

In Me4, nothing happens - "Abc" remains visible and retrievable.

 

Pleased to see that so clearly stated. I've been puzzling over why several of macros aren't working in ME Pro, all concerned with the clipboard behaviour.

 

Have you reported that as an ME Pro bug?

 

--

Terry, East Grinstead, UK

[paul]

No, because I'm not sure it is a bug! You can argue for or against writing an empty variable to the clipboard. Just because ME3 does it one way does not necessarily mean ME4 should do it the same way, I suppose. Empty can mean "never used, does not exist" or "used, and reset to empty" or empty, which is a valid value in its own right!

 

In another topic, a question was asked about whether an variable is the same as a null variable. In ME terms, the answer is probably Yes. But in the database world NULL can mean very many different things.

 

Suppose a record where Phone is NULL. This could mean any of the following:

The user:

- doesn't have a phone

- doesn't know if he's got a phone

- has a phone, but doesn't know the number

- has a phone and won't tell us the number

- forgot to fill the field in

There are probably more meanings. But quite often it's important to be able to distinguish between a variable never having been initialized versus being initialized to ""

[paul]

I have tested with Clipmate enabled, Clipmate disabled and Clipmate not loaded. But I haven't tried uninstalling Clipmate.

[rberq]

Just because ME3 does it one way does not necessarily mean ME4 should do it the same way, I suppose....

 

I totally disagree. A lot of $$$ go into developing software applications around something like ME. It absolutely should work the same between one release and the next. Don't accept the sloppy crack-brained Microsoft philosophy of "similar is close enough when we put out a new release, we're so big we don't have to be good". That attitude is why I keep a collection jar on my desk for the Send Bill Gates to Jail Fund.

 

Granted, ME has a disclaimer, something like "This is OK software, but don't rely on it to control medical devices in the Intensive Care Unit, or to monitor systems in your nuclear power plant." But something as basic as that should work the same, or is should be documented as a release difference.