www.virtualacorn.co.uk/forum

This keeps happening...
On switching to VRPC full screen I frequently notice that there is a slight sluggishness. Then, as soon as I open a window that takes key input its obvious why. Continuous key events are being received. Usually it is Ctrl-M (Return) and a quick check with WimpInfo shows (repeated indefinately):
StrongED received event Key Pressed
at offset (1,0) from origin of desktop background
key pressed is Return (Ctrl-M)
Task Manager received event Key Pressed
at offset (1,0) from origin of desktop background
key pressed is Return (Ctrl-M)
Director received event Key Pressed
at offset (1,0) from origin of desktop background
key pressed is Return (Ctrl-M)

Entering Escape stops the continuous key events, but as soon as I switch out of full screen and back the continous key events start again and sometimes they start again whilst using VRPC without switching out of full screen. So far I have found that only rebooting VRPC fixes the problem.
A slight variation on this problem is that all keypresses result in top-bit-set characters being entered (as if the Alt key was stuck down).

This has been the same with two different USB keyboards and although it happens less often it also occurs on my VRPC-SA system.

For what its worth there is another clue to the problem. It always seems to happen when VRPC has been minimized for a long time.

Any ideas?

This can happen, but it's very rare. RISC OS receives the "key down" event, but doesn't receive the corresponding "key up" event. Pressing the key that's "stuck" will stop the auto repeat, as both a new "key down" and a "key up" will get generated.

Having said this (and I pressume that this SE version is up to date) this coupled with the other problems that you are having lead me to suggest that a new computer might be the way to go.

The SE version is up to date. The thought of a new computer has been on my mind for a long time. The machine has been running 24x7 for over 2 years and the accumulation of security and ant-virus updates seems to progressively slow it down (I've seen this on every Win PC I've had). It also seems to be getting more frequent weird Windows hangs, missing icons, and other odd behaviour. I also think that the reason for the changed behaviour when VRPC has been minimized a long time is probably not due to the length of time but nore likely the fact that other memory-hungry applications have been run and caused VRPC to be swapped out. Windows doesn't seem to re-prioritise VRPC to give it the responsiveness it had initially unless its rebooted. This probably means my next computer should have at least 2GB memory (the current one has 1GB). Also, whilst the computer is very small and very quiet (an XPC Shuttle) the Centrino 1.6GHz dual processor seems to have become under powered as applications get more and more power-hungry and I have a number of permanently running services such as Apache, network monitoring and temperature monitoring. The 3GHz 1GB machine at work (running VRPC-SA) has fewer problems. The main issues are that its a bad time for us financially, I need to find a machine that is NOT going to be bogged down by Vista, and I don't want a noisey-fan machine (it has to be in the lounge).

A little more info about this...
Entering Return does not stop the continuous key events. Escape stops it temporarily, but as soon as Return is pressed the continuous events start again. Entering a Return using FX138 or FX152 is not the same and doesn't trigger the problem. So it would seem the problem is somewhere in the interface between the Windows and VRPC.
Its obviously not as simple as a missed keyup event. Something is lodging a keyevent in a buffer and its not getting cleared when its read.

Resetting the USB keyboard doesn't stop the problem once it has started, and as I said before, two different keyboards have been used, so its not the keyboard hardware.
The fact that this occurs on two different systems (one SE and one SA) and with totally different hardware suggests its not hardware related at all.

When this first occured on the SA system I thought it was the KVM switch but actually it seems that its not that at all. In that case however the key press that gets stuck is usually "2" as thats the last key pressed on switching using the KVM switch. Continuous key events rarely happens on AltEnter on that system but its annoyingly frequent on the other (and that doesn't have a KVM switch, its directly connected USB).

Your reported symptoms keep ringing bells as ISTR we briefly had a similar set of circumstances some years ago (so probably affecting VirtualRPC-SE, although that may not be relevant). It did however affect VirtualRPC/RISC OS and not the underlying Windows XP, SP2.

Like you, we tried different keyboards and mice, without clearing the problems. This affected only one machine of four, the others running identical versions of Windows XP, VirtualRPC-SE, RISC OS v4.02 etc, so we concluded it might be a hardware issue with that particular host PC.

The working fix was simple: Plug both the (existing) keyboard and mouse into separate 'primary' USB sockets on the computer - no more problems. By 'primary', I mean avoid 'secondary' USB sockets such as those combined with a card reader, on a plug-in multi-way USB adaptor, or 'daisy-chained' e.g. on the back of the keyboard. Also I suggest try it without the KVM switch in the loop.

This may have been a timing issue, or that some of the 'secondary' sockets were USB1 and not USB2. I dunno, but a fix is a fix - especially if it's permanent.

HTH
Mike Nicholl
pp T.O.M.S.

It could be a problem with there being "too much traffic" on a particular USB interface. Or it could even be caused by a PS" keyboard connected via a USB adapater.

When a key gets stuck the only way to stop it is to press the same key again. Pressing other keys might stop it for a moment or to - but the "key up" event needs to be generated.

However given that this machine has multiple problems in Windows, it's not suprising that these problems manifest themselves in Windows applications.

If you do decide on a new machine I would suggest:

Intel Core 2 Quad (or i7 if you can afford it).
At least 2GB of RAM.
Decent graphics card (ATI) with DirectX 10 support

OK, I did get a new computer but I want to report what just happened on my other machine (3 GHz 4 core with 1GB mem and VRPC-SA) because it seems likely to be a related symptom.
I was just working in a TechWriter document, entering text (it was ages since I switched to RISC OS from Windows) and suddenly the mouse pointer stopped moving latterally. Many keys failed to do anything. I tried Alt-break and in the end with reluctance I had to quit TechWriter and loose my work. The mouse pointer got freed but many key presses would not work. I opened an Edit window and found that all key presses were top-bit-set characters (I've seen this many times before but always previously its been immediately after a switch to VRPC from Windows, and only on the slower VRPC-SE machine).
Then, when I tried to run !XChars, there was a few flashes of bits of Windows applications on top of the RISC OS screen and then the white Windows pointer appeared and as I moved it around, various bits of Windows apps flickered. I pressed Alt-Enter and Alt-Enter again and eventually got normal RISC OS back. The top-bit-set key entry also stopped. However, the weird thing is that when I went back to Windows I found a new File Explorer window open displaying the !XChars directory!! So, somehow the action of running !XChars in RISC OS got through to Windows as a double click on the !XChars directory.
Is that a valuable clue, or does it add to the confusion?

Wow, time flies. This topic started a couple of years ago!
After speculation about various possible causes I thought I would just log the fact that I've just seen the problem on the laptop. The first thing I noticed was that VRPC was using 45% of the dual core machine (90% of one CPU). Then I noticed that when I tried to shut VRPC down the confirmation dialogue window just flashed up for a split second. When I opened a task window the cause became obvious - continuous RETURN keypresses being injected.
I don't use the laptop much so I have not seen the problem on the laptop before, but its now happened on all my computers and all versions of VRPC. On the laptop I had two USB devices - mouse and USB memory stick. Maybe USB activity caused a key up to get lost.

I think the fact that you have only just seen the problem occur again after 2 years would indicate that it's going to be difficult to reproduce reliably under controlled conditions. A dirty keyboard could (remotely) be the cause, or it could well be caused by some other application.

I should say that I have seen the problem once last year some time. Pressing the 'stuck' key again stopped the ASCII entry into the keyboard buffer and it hasn't happened since.

I know this is so intermittent that the cause may never be found and I accept that. The reason for reporting it this time was twofold. 1) its the first time I have seen it on the laptop (where its a pristene machine where keys don't get stuck and there is no KVM switch or other suspect hardware), 2) in case other users can say whether they have seen this which might add clues as to the root cause (and if people see dialogue windows flash momentarily and CPU usage go to 90% they might suspect the cause is the contiuous key injection)
I think in every case (and I have seen the symptoms on all the VRPC installations on all the computers I've had) its never been an actual stuck key. The state of continuous key injection is purely in the software (although a transient hardware glitch might have initiated it). The condition always occurs on transition between Windows desktop and VRPC full screen. Sometimes the condition affects the state of the CapsLock so that Windows and VRPC get out of sync, one having CapsLock on and the other off whilst the keyboard state stays the same.
It is perhaps noteworthy that by far the most common keys to be continuously injected are Return, 1 or 2. These are the keys used (Alt+Return) to flip between Win desktop an VRPC, and 1 and 2 are the ksys used on the KVM switch to change machines (which is why for a long time I suspected the KVM switch). Mostly ithe the Return key.
I also notice that sometimes keypreses get lost. I've mentioned this before and its not generally s serious problem (although a long time age it was). Since this happens I suspect that maybe, during the Alt+Enter processing a key-up gets lost so the Enter/Return key is thought by the system to be held down.
Anyway, you don't need to reply to this. I'm just logging clues that might one day lead to an understanding of the cause.