Jim, since you are 3 or 4 AUs closer to the inner circle than me please pass this list along to someone nearer to the core than yourself.

As a longtime user of FPD 2.0 (and on) I have a few gripes/questions about VFP. Maybe some of these things would be deemed worthy of consideration in VFP 7.0, maybe we already have some of them and I just don't know about them.

1. One of my gripes with VFP is that we (VFP users) have to perform a clumsy API call to disable the development environment when our apps start, and even then the development environment has to pop up and go away before our main form instantiates. Do you have any insight into just why that is and why MS hasn't seen fit to give us the ability to cleanly define a start form like the VB guys do? Failure of MS to provide this simple feature is unforgivable. This gives first time users who may be making the VFP / VB / VC decision a very bad taste for VFP to begin with and I think that many choose the VB route because of it. Sure, if they knew the whole story they'd probably pick VFP but many are put off by this shortcoming in VFP.

2. Along those lines isn't there a clean way to make things such as copy and paste (and other utilities or behaviors) available without referencing them by their menu related aliases? Why can't I just SET COPYPASTE ON instead of having to put up a menu with _MED_COPY and _MED_PASTE? Like so many things I could write a wrapper for this but it should be built into the product.

Obviously I'm in favor of VFP ruling the world so that my income potential as one of the new elite will be virtually unlimited. Mwahahaha!!!
3. Why does VFP have a different interface (probably not the correct term) with OCX controls than VB? Frequently when I use Active X controls there are caveats concerning whether or not (and to what extent) they will work with VFP. The story I always get is that VFP treats Active X controls "differently". The VFP gurus imply that VFP forces an OCX to stringently adhere to the "rules" and that VB doesn't. Since (apparently) most OCXs are coded sloppily (and tested with VB only) this creates problems. Why can't we have a SET statement (and the underlying spaghetti code that we'll never see) for this? SET OCXTYPE TO vb | vfp?

4. What is the deal with SYS(xxxx)? Why do they have to live on the fringe as function wannabes? Take the SYS calls used to handle Julian dates for example. SYS(1) should be JDATE(), SYS(10) should be NTOJ(), and SYS(11) should be JTON(). Call me crazy but almost all of the SYS calls could stand a good renaming. Sure we could all write little wrappers but MS has to name these things something, why not take the time to name them something meaningful?

5. Since they have done such a phenominally bad job of marketing VFP do you think they (MS) would ever consider naming it something different as of the next release and putting a new marketing effort behind it. I'm sure Dr. Dave would hate it but how about Visual Data Manager or UltraSuperPowerBuilder (much better than PowerBuilder) or
InfalliblePrognosticator (as opposed to Delphi)? Seriously though, any thoughts regarding a new name or a new marketing effort?

Obviously I'd like to see VFP take over the world so that my earning potential as one of the new elite will be virtually unlimited. Mwahahaha!!!!