I'm leaning toward something internally in the vfp program that for some reason is only occuring on their systems though. I would find it difficult to believe that every keyboard port is to blame on those systems. Plus, we use those same computers/motherboards at other locations as well with no problems.


>I know you said you replaced the keyboard, but it may be the keyboard port on the motherboard. Isn't there also software that can re-map each keystroke?
>
>
>>Any ideas anyone? What would make all keys return the equivalent to chr(152)?
>>
>>>I have a process that a user goes through maybe 30 times a day. The steps are always the same. This happens at literally hundreds of locations. However, on all of the machines at one single location a strange thing happens. When the user goes to a form and the form displays, all of the fields will be accessible but the cursor dissappears. Clicking in any field on the form the user can type but the cursor is not visible. The strangest thing is that no matter what key the user presses on the keyboard, the (ctrl+F1) key is the result (a 'y' with the two umlauts on top of it) in all fields. Now, the titlebar of the form itself actually appears disabled, but the form is not disabled. The REALLY strange this is that if the user presses the windows key on the keyboard (which activates the startmenu in windows) and then clicks with the mouse on the titlebar of the form in VFP, everything returns to normal and the titlebar is now dark, the keys work correctly in all fields, and
>>>the cursor is active. Once this problem occurs, it happens everytime until I delete the resource file and restart our app (or so it appears).
>>>
>>>All of the systems are new systems.
>>>Windows XP.
>>>6 workstations.
>>>Printing is done through printer sharing.
>>>This app is actually a vfp8 app. DLLS are stored in common files.
>>>Another 3rd party app exists but all of its DLLS and the app are stored in a single directory on the server. No files on the local workstations. Resource for that app is set to OFF in its config.fpw (I checked). I also verified after deleting our resource file that no other resource files were created on the workstation or the server when the other app opens so resource is definitely set off for that app.
>>>When the form is initially displayed it appears disabled but is not (the title bar is dimmed). Pressing any key in any field displays the y with the umlaut on it. Without doing anything else, if I press the windows key on the keyboard and then click on the titlebar of my app the form becomes completely enabled and all keys work as they should. When the form initially displays I cannot click on the titlebar of the form unless I first press the windows key on the keyboard to shift focus. The mouse does not seem to work to activate the form but it does in fact work because I can click in a field and type the number 1 for instance (even though the cursor is not visible) and the result is the y with the umlaut displayed in the field.
>>>
>>>I have checked the power settings, desktop themes, resource files, other vfp apps and their files, replaced the keyboard, etc. It will only happen at this site and then it is reproduced nonstop.
>>>
>>>Any ideas? Why does switching tasks to/from windows startmenu fix it? The form is the same form that has run for years (and called in the same sequence) by hundreds of users.
>>>
>>>TIA