Unresponsive menu in VFP running on Windows Server 2008

[tamayok]

Hi,

I am having a problem in a client site where the main/std. top menu of a VFP9-SP2 application is unresponsive.

An identical issue was raised by another member of Tek-Tips back in 2011 under thread # 1662520, unfortunately, the updating of the mouse driver did not solve the problem. The application is being tested on the desktop of a 64-bit Windows Server 2008 R2. I can confirm the problem by accessing it via a Remote Desktop session: The user clicks the menu but it doesn't 'react', however, it DOES work as expected when the menu is initially 'activated' via the keyboard (by Left-ALT or F10) and the sub-sequently mouse-driven.

I have tried some odd solutions (choosing a different Font Size and even a different Font via the Windows options) but the same lack of menu response takes place. Every other object/control in the application responds to the mouse as expected.

I can also confirm that the issue is NOT present in another Windows Server 2008 R2 SP1 hosted elsewhere. The problem is only taking place there as far as I can see.

 

[Dan Freeman]

If I understand you correctly, your problem is:

Your application works fine on one Win2008 R2 SP1 server, but fails on another Win2008 R2 SP1 server?

Seems to me you need to find out what's different about those two servers. There are a LOT of server tweaks an administrator can make, and usually completely forget about making, so it can be difficult to track down.

Good luck!

 

[tamayok]

Hi danfreeman,

To illustrate in other other words:

The application works perfectly in both but the app. menu (basically a variation of options based on the std. File, View, Help...) does not respond to mouse clicks in one of these. You click, say on 'Help' and the corresponding 'Help' options are not shown. If, on the other hand, you use the keyboard (ALT or F10), the menu is responsive and once the corresponding options are displayed, THEN the mouse is capable of selecting/clicking them as you would expect.

This has happened to others, as mentioned in thread 1662520. The solution offered there was to change the HID/mouse driver but it didn't work for me as the system insists it already has the current/'best' driver installed/in use.

 

[Dan Freeman]

Yes, I understood you and as I said THIS IS NOT A FOXPRO ISSUE.

Even in that other thread, the solution was system-related just as yours will be. Nobody can guess in advance what that solution will be.

As far as mouse drivers go, having the most current driver won't help you a bit if the most current driver is buggy. In that case, you'd want to *NOT* have the most current driver at all!

Again, you need to find out the difference between those two servers. You have a perfect laboratory with one working example and one non-working example. What's the difference between the two?

 

[tamayok]

Thanks danfreeman,

Appreciate your input. The perfect laboratory is not quite: 1 server is my own, the other is at my clients'. The only thing in common is the OS... but if I bump into the solution I will be posting here.

Btw, if it was an issue taking place with ANY other application/GUI in that server perhaps it would have been someone else's problem, but it is not, it is only happening in my VFP app, so I am guilty somehow until I can prove otherwise by means of a solution. I will try some other options (like installing some other small./vfp app if they allow me) and take it from there.

Again, thanks for input.

 

[Olaf Doschke]

> the system insists it already has the current/'best' driver installed/in use
This message, while not related to VFP, is known as misleading. If you have the latest/best driver for the wrong device, the OS still will display that message, so that messagee is no quality assurance at all. It only says what it say, it doesn't say anything about having the right driver.

My advice would be: Remove the mouse device (or bluetooth dongle, if it's a bluetooth connected mouse), remove the driver, plug in a new/other mouse.
The OS will then retrieve another driver, which presumably will work.

Bye, Olaf.

 

[tamayok]

Thanks OlafDoschke,

I will try that next time I am granted access to the server.

 

[Olaf Doschke]

OK, but how about telling them, you can't do it remotely anyway, you have to it next time you're there, some admin of them should be able to do it.

Bye, Olaf.

 

[Dan Freeman]

Btw, if it was an issue taking place with ANY other application/GUI in that server perhaps it would have been someone else's problem, but it is not, it is only happening in my VFP app, so I am guilty somehow until I can prove otherwise by means of a solution. I will try some other options (like installing some other small./vfp app if they allow me) and take it from there.

You have my sympathy. We've all been there.

VFP is the "great breaker". It is hard on hardware. If there's a flaky memory chip, VFP will find and exploit it. If there's a chip that needs wiggling on a video board, VFP will be the only application bothered by it. If there's a staple through an ethernet cable somewhere in the building, VFP will notice.

I once had a six-hour conference call with a client and reps from Microsoft over a failure that occurred on one out of three servers. We could exactly replicate the same software and the same data on all three servers and reliably reproduce the failure on only one of the servers. Even Microsoft's techs kept asking what was wrong with our software even after watching the software work properly on two out of three servers.

In the end, the client's admin bashfully admitted she'd used the wrong disk image to install that one server. Once she used the "blessed" image, things worked normally.

These things aren't always easy to track down. Good luck!