Keystrokes getting lost on the way to SUT

Eggplant Functional
1

Here is one that’s been frustrating me for a few weeks. I think it’s an issue in the Windows XP Remote Desktop Client, but there’s no way I can tell this for sure.

Let’s start by understanding that I do not have access to a direct connection to the actual (logical) SUT. That belongs to a third party, and for security reasons, I am not able to load any VNC servers on that box.

That means that I need to use an indirect means of communicating with it, and to that end, I have a local VM running VNC - which becomes a physical SUT - that then connects to the logical SUT using Microsoft Remote Desktop.

So, I connect from Eggplant using VNC to the physical (local) SUT, which then connects to the logical (remote) SUT using RDC. To emulate this locally, I have a second XP VM set up, and I can use RDC to access that system as a substitute for the real logical SUT.

Still with me? :slight_smile:

Mac (192.168.0.102) -> Physical XP SUT via VNC
Physical XP SUT (192.168.0.71) -> Logical XP SUT via RDC
Logical XP SUT (192.168.0.58, or third party)

Now, what happens is that when I send some text from the Mac to the logical SUT, it is mostly ok.

Mostly ok means that sometimes it is not, and therein lies the problem: I may send a text string of “ABCDE”, but the logical SUT gets perhaps “aBCDE”, or even “abcde”.

Basically, shift and/or control characters seem to be getting lost somewhere in the ether.

Here’s how to set up the test and try this for yourself:

1: set up the local environment as described above, with a Mac and two XP VMs. Obviously, use IP addresses that are reasonable for your own situation.

From Eggplant, connect to the first XP VM using the Eggplant connection list. This is the physical SUT.

From within that connection, use the MS Remote Desktop Client to connect to the secondary XP VM. This is the logical SUT - it’s where we are actually doing our testing, even though we are not directly connected to it.

Within the logical SUT load a copy of Notepad, and then run this script.


set loops = 0
repeat until loops = 10
	typetext "TEST #" & Loops & "
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
	typetext "ABCDE
"
		
	// Let's wait a couple of seconds, and see if 
	// everything has been brought across correctly			
	wait 4

	// Let's clear the workarea, and start again	
	typetext "\ca\C"
	typetext "\D"

	set loops = loops + 1
end repeat

As you can see, there’s a small pause inserted in this script to permit you some time to have a quick look at what’s actually been typed into Notepad. If you see any lowercase characters at all - any - then you are seeing the issue I’m talking about.

In my tests, I’ve seen similar results when using RealVNC or TightVNC. That suggests to me that the problem lies within either Eggplant or the MS RDC.

If I modify the test so that I use VNC into the host Mac instead of the intermediate XP VM …

Mac (192.168.0.102) -> Physical Mac SUT via Vine
Physical Mac SUT (192.168.0.102) -> Logical XP SUT via MS Mac RDC
Logical XP SUT (192.168.0.58, or third party)

I do not see this problem, which, to my way of thinking, kind of removes Eggplant as the source of the issue.

Does anybody else get similar results to what I’ve been getting?

Does anyone understand what is happening here? This seems to be associated with keyboard state settings, rather than scancodes that should be being sent.

Oh yes, XP is always SP2.

TIA for any thoughts on this one.

2

Gary:

Have you tried increasing your key down delay and your next key delay. Give your level of indirection I think you want to increase those values (maybe even by a factor of 10).

You can do that globally by setting the value in Eggplant->Preferences->Run Options->Keyboard.

Or you can control that from within your script with

set the KeyDownDelay to 0.01
set the NextKeyDelay to 0.1

I suspect that will help your situation a lot, but let us know if it doesn’t clear it up for you.

3

Doesn’t seem to help.

First of all, the example you’ve given (obviously a typo) of 0.0.1 fails.

If I increase the keydowndelay value (say from 0.01 to 0.1) it seems to worsen the problem - hard to say, but the problem manifests itself more quickly.

If I increase the NextKeyDelay (0.1 -> 1.0 -> 2.0 ), it just seems to slow stuff down (as would be expected) but doesn’t really seem to improve or worsen the problem.

Cheers.

4

I suggest you try playing with the SendShiftForCaps option to see what difference it makes. You can set the default value for this under Preferences -> Run Options -> Keyboard. Basically, when that option is set to true, Eggplant will send shiftKey down and up events for every capital letter that is being typed. It seems clear that some of these events are being lost somewhere along the line.

To experiment with this, you might try something along these lines:

set SendShiftForCaps to false
typeText shiftKeyDown
repeat 10 times
    typeText "ABCDE" & return
end repeat
typeText shiftKeyUp

See what difference (if any) that makes, and perhaps that will give us more clues about how to fix it. Working through multiple layers of SUTs is more challenging (obviously!) so simplifying and reducing the events that are being sent may help. Different VNC servers process key events slightly differently. You may find that you don’t need to explicitly send the shiftKey at all, so experiment a bit and see what happens.

5

Not a whole lot, I’m afraid.

With the repeat counter set to 10 instances, it seemed to be ok. Increasing it to 100 gave me three errors. While three seems to be better than it was, zero is, of course, what I need. :slight_smile:

FWIW, I’m not sure that it’s making a whole lot of difference, because when I left the counter at 100, and then used “set SendShiftForCaps to true”, the resulting run gave me a further two errors, hence my initial response that this is not making a whole lot of difference.

As an aside, is the line in your sample script “typeText shiftKeyDown” supposed to do something? It just types shiftKeyDown as a literal in the SUT, rather than actually acting as a command.

6

My mistake: that should have been shiftDown. And I see I made one more unpardonable error – the first line of my earlier example should have read:

set THE SendShiftForCaps to false

The word “the” doesn’t have to be capitalized, but without it the script sets a local variable, not the intended global property! :oops: Oops! I apologize – looks like I was posting code too early in the morning (or at least that’s my lame excuse).

Maybe correcting that mistake will help. If not, I’m running out of ideas at the moment, unless some combination of these suggestions might help. By setting the SendShiftForCaps to false you are turning off Eggplant’s “hidden” behavior of sending shiftKey down and up events along with the regular key down and up when typing capital letters. So then shift key events should only be sent when you explicitly request them.

It seems like the problem has to be caused by some shiftKey events not being noticed by Remote Desktop (either the client or the server in that connection). I think the most likely reason for those events to be missed is because they are coming too fast so that events are arriving one after another in a way that the system is unable to handle.

So here’s one more idea: If you want to try being very explicit, you can drop down to using the low-level KeyDown and KeyUp commands, and control the timing yourself. This would look something like this:

put the remoteWorkInterval into savedRWI -- save for restoring later
set the remoteWorkInterval to 0 -- no delay; control it directly
set the sendShiftForCaps to false
set localKeyDownDelay to 0.001 -- try different values here
set localNextKeyDelay to 0.01
keyDown shiftKey -- try putting shift down once for the entire time
repeat 10 times
  repeat with theKey = each char of "ABCDE" & return
    wait localNextKeyDelay
    keyDown theKey -- press the key
    wait localKeyDownDelay
    keyUp theKey -- release it again
  end repeat
end repeat
keyUp shiftKey -- be sure to release it again.
set the remoteWorkInterval to savedRWI -- restore the RWI

Usually Eggplant’s built-in timings work well, but obviously you don’t have a usual situation here. Doing something like this will allow you to tweak the timing and the use of the shift key to see if you can figure out what causes it to break and hopefully find a combination that will work!

Good luck!

7

Doug,

Thanx for your help thus far. I think I may have a solution, although I’ve not yet tested this within the actual test environment, my internal tests have been 100% successful, which is somewhat indicative that this might work.

Based upon your suggested methodologies, I’ve created a helper script called MyTypeText, with the following code …


to handle MyTypeText
	params ToType
	
	set localKeyDownDelay to 0.1 -- try different values here
	set localNextKeyDelay to 0.1
	
	set the SendShiftForCaps to false
	repeat with theKey = each char of ToType
		wait localNextKeyDelay
		typetext theKey -- press the key
		wait localKeyDownDelay
	end repeat
	set the SendShiftForCaps to true
	
end MyTypeText

Within my local test environment I was able to send more than 2000 sets of text strings (varying between 5 and 10 characters each) with a 100% success rate.

While this slows down the input a little, I only need to use this code selectively - where I’m creating a user or object identifier, for instance, or creating or using a password - times when the case sensitivity truly matters.

I should know more about how good this solution really is over the course of the next week or so. :slight_smile:

8

In the actual setup, this is still not working reliably enough. :frowning:

I have increased the value of localKeyDownDelay to 0.2 with no noticeable improvement.

Any other suggestions while I play with more value settings?