Wit's end (with remote clipboard)

You might know the place, inhabited by trolls, throwing axes, guarding the only way to town and all of that.

I’m trying to write a windows routine to capture crash data and it seems that the remote clipboard function is actually blocked by the crash, or just generally misbehaving. The routines work in “simulation mode”, I can copy text from the windows SUT running VNC 412, but now it seems that whenever I run into a crash, the clipboard cannot be sent, I can copy the data just fine (it’s on the clipboard after I exit the misbehaving app and try to paste it)

It’s a basic EP script, nothing fancy at all, I mean nothing fancy period, find the crash dialog, grab the text, toss the copy command and try to put remoteclipboard (15) into error_text, pretty much the same as I have done with some good results previous.

I thought it may have been the 10.4.9 issue, so I moved my entire environment to a new 10.4.3 install and switched off software “updates”

I should mention that I have no problem grabbing text from a Net 1.1 exception handler, that works nicely, except our other app doesn’t use Net 1.1 framework, it’s using Microsoft Foundation class.

So, do I distract the troll with doug(hnuts) and try to sneak my data across the bridge, or am I forever trapped at wit’s end as I failed to get the can of oil to quiet the squeaky gate in time?

Not being able to reliably capture the crash dialog as text is going to make mailing it into our bug database a rather data intensive issue and require a separate approach for each product, something I’m just not keen on doing.

Any and all suggestions welcome, but I should mention that the MFC crash dialog has focus in a big way, so even getting to another application to dump the data is a bit problematic.

Did you try kill dragon? If it doesn’t work with your bare hands then posting here is a good thing to do.

For our next release we have fixed a couple of “clipboard sharing” issues that show up in Eggplant (3.21). Some of them have to do with rich clipboards (which you shouldn’t be hitting going to a Windows machine).

Another has to do with getting the rich mouse cursor, you can disable that in the Eggplant->Preferences->VNC by clicking off “Rich Cursors” and then clicking off and on again for one of the other encodings. That might help.

You might also want to be sure that you are ONLY connected to the single SUT at the time you request the clipboard data – there is another rare but possible bug if you are connected to multiple SUTs.

Finally you should be sure to use the RemoteClipboard function with a timing parameter. Because of the nature of the VNC clipboard it’s not a synchronous request and so doing it with 5 second explicit time should allow enough time for Eggplant to get the data.

If all those suggestions still don’t work try xyzzy and then plugh.

Now would be a good time to head east into the woods and find a lighter, a mace, a flashlight, and a sandwich and march to the nearest cave and read the EP and ST manuals :slight_smile:

Couple of things I should mention…

I’m using 3.31 EP and also using the remoteclipboard (15) command

Before I run the script that generates the crash I can move clip data easily in both directions.

Single sut may have had a play in this, but I was wondering about VNC settings that might help…I’ve just installed a raft of windows updates on the SUT and rebooted it for good measure, perhaps that is the root of the problem, the SUT in this case has been running for weeks without a reboot and perhaps had some issues.

I’ll be giving it another go today.

I found that plugh has some intresting side effects when used in a script as a literal, seems to turn on my espresso machine …and make my hard disk spin backwards when used as a variable name.

For those of you scratching your heads about all of the “secret handshake talk” ( a super duper minor reverse subset of sensetalk)…:

yeah…we’re brutally old (some of us)

The end result:

I tried quite a few things, going with VNC as a service instead of an App, various settings and even a little green goo tossed in for good measure.

End result:

The app is crashing in this circumstance in such a way in one of the many modules it has as to block the clipboard transmission! to EP with VNC 4.1.2

I went on to greener bug pastures and ran into a similar crash dialog (a different part of the product functionality) and the clipboard data was reliably sent and injected into the appropriate places.

So I have to go with a try/catch that detects the clipboard transfer failure and simply goes with the screen shot instead.

Not as tidy as I planned, but when does planning for bug detection ever work as designed?..we plan…and the compilers simply laugh…and laugh.

:idea: Oh yes…I even took a huge chance and installed Tight VNC on the SUT, in the event that realvnc was the culprit.

No fault no foul here…just something to save somebody else the heartache of losing several hours of time chasing this one around.