PMJIA, but I think I can answer some of your questions. Also, you can send your requests directly to the VFP team. Email FoxWish@microsoft.com.

>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.

This really is a personal thing. I really dislike top level forms for most applications. There really is nothing wrong with using the VFP screen (_SCREEN) for you application. Just launch Word or Excel and close all open documents/spreadsheets. Looks like VFP to me. There are also some things that are more difficult to do with top level forms. Report Preview for one. As for your "clumsy API calls", just put SCREEN=OFF in the CONFIG.FPW.


>
>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.

I agree. This area could use some improvement.

>
>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?

AutoYield does some of this for you. The answer really lies into the evolution of the two product. VB was designed to handle these types of controls in the beginning (remember VBX). VFP has LOTS of legacy code dating back to the FoxPro 2.0 days (and maybe even earlier) that still exists in the core product.

>
>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?

Again, this goes back to the legacy days when the C compiler Fox Software was using limited the number of function names they could use. Personally, I see no reason to rename them. It would merely add to code bloat. You can't just get rid of them because existing applications would break.

>
>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?

Bad??? You need to look around. VFP marketing is now better than it's ever been. Renaming the product would actually be a bad idea. That would mean a huge marketing effort to get the name out and all people would say is "It's just VFP with a different name." Renaming something just for marketing purposes is a bad idea.


>
>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!!!!