Yep - and this is indeed a problem. I think the fact that the controls are not really 'windows' has something to do with VFP 3.0 and Micro$oft trying to make VFP work on the MAC's.
There are things you can do to make your VFP application look more modern - create dashboards, use lots of skins and ribbon-controls to give it the office 2007 feel - but there isn't anything you can really do about the controls on the form - yer stuck with those.
At first you could get away with simply tweaking the look & fell of your VFP app to make it more modern - but now with all the winblows 7 aero glass features and such it's just not feasable anymore.


>The problem with skinning VFP controls is they aren't really controls. They're closer to bitmaps.
>
>There's nothing to stop you from creating a WPF control and COM-enabling it, then dropping it on a VFP form. But then, why not just use WPF in the first place?
>
>>VFP=C was a Tongue-in-cheeck suggestion, I suppose...
>>
>>Unless somebody comes up with modern skins for VFP that cover every type of form and control and that are not a kludge to insert into applications, even a baby can soon tell that a given app was written with "some legacy software", because it looks so different (=ancient.) Compare VFP apps to the latest Windows 7 "Aero glass" apps (like Silverlight), and there is nowhere to hide the fact that this stuff is ancient. Since perception is so often reality, a lot of people will shy away from VFP apps sooner rather than later, regardless of how good the apps themselves might be.
>>
>>Then there are of course the IT staffers who are extremely suspicious of "something called Foxpro running inside our network." My experience has been that a VFP app gives IT people the perfect excuse to turn the blaming, bony finger at Foxpro when the network slows down or crashes or gets infected or what have you.