I am revisiting an AREV 3.1 application I wrote for a client a number of years ago and has been running fine on a Windows 98 Peer-to-Peer network. The client has just upgraded to Windows XP and has a problem running AREV in fullscreen mode, namely there is no response to the keyboard. Running in Windowed mode is fine.

The computer isn't locking up as I can switch back to the desktop and everything is alive.

The same thing is happening on my PC (standalone) but the wierd thing is it was working OK a few days ago and I can't think what, if anything, I have changed to cause the change to AREV's behaviour.

Can anyone suggest a solution?

Regards

Adrian Collings

T have the same, or least a similar problem. The cursor gets lost. No solution, but a work around is to switch to windowed mode and then back to full screen.

Switching to Windowed mode doesn't make any difference, in fact there is still no response to the keyboard while it's in windowed mode. Only starting up in windowed mode initially allows keyboard input.

Regards

Adrian

I've never tried running full screen on XP, but we have recently been playing around with a utility called "TameDos" which seems to help somewhat with the issue of NTVDM hogging up the processor resources, which might in turn be causing a keyboard delay? It's available at www.tamedos.com

HTH

Chip

Just a thought:

Try \ \ Utilities \ Configure \ Workstation \ Display \ Environment

at Video Display Mode - select DEFAULT press enter so at Font…

Exit

Then back in

This fixes "Half full Screen" display problems. It may be associated.

Barry

We have removed tame recently …

We have had problems with "freezing" on XP stations (NLM) after an idle. We run in three directions 1) Tame 2) Replace background (checks "message file" for non indexing stations and prints message when presented … it yelds time for windows) 3) Universal driver

Replace background solved the problem, tame was not as successful … the problem was probably that Novell does not obtain a packet for a long time and left the connection? Checking for "message file" sended the required packet. After installing UD we observe that tame slows down machine a lot so we remove it even on testing machine. I hate updates, but at least for now:) it seems that UD was good choise (10 to 20 speedup).

We have removed tame recently …

We have had problems with "freezing" on XP stations (NLM) after an idle. We run in three directions 1) Tame 2) Replace background (checks "message file" for non indexing stations and prints message when presented … it yelds time for windows) 3) Universal driver

Replace background solved the problem, tame was not as successful … the problem was probably that Novell does not obtain a packet for a long time and left the connection? Checking for "message file" sended the required packet. After installing UD we observe that tame slows down machine a lot so we remove it even on testing machine. I hate updates, but at least for now:) it seems that UD was good choise (10 to 20 speedup).

We have removed tame recently …

We have had problems with "freezing" on XP stations (NLM) after an idle. We run in three directions 1) Tame 2) Replace background (checks "message file" for non indexing stations and prints message when presented … it yelds time for windows) 3) Universal driver

Replace background solved the problem, tame was not as successful … the problem was probably that Novell does not obtain a packet for a long time and left the connection? Checking for "message file" sended the required packet. After installing UD we observe that tame slows down machine a lot so we remove it even on testing machine. I hate updates, but at least for now:) it seems that UD was good choise (10 to 20 speedup).

View this thread on the forum...