Hi!

Thanks Randy!

My greatest wish is that VFP team consult and discuss certain things more with VFP community, specially about implementing new features or about ERs. It could be here at UT (excellent engine for discussions), or just tell us where to look if MS VFP team already do such discussions somewhere else.

As about the ERs database, do you have something like the 'priority' and 'votes'? Jim Nelson given an excellent idea about votes for wish - to see how many developers want to see certain thing in new version of VFP. Based on votes you will see what feature is really needed. Based on votes AND cost of implementation determine the priority of the ER to implement in the next version. When there are certain difficulties in implementation or implementing will cause conflicts with existing functionality, just discuss this with VFP community.

Personally, I wouldn't mind focusing on features that have direct impact in the apps you ship, such as ERs in OOP, Data, Web, Form and Controls improvements.

Well, you can make just a now control. For example, I wish Grid reconstruction behavior is fixes finally (see FAQ#8019). If you think it will impact existing applications - well, you can jsut create ... new grid control. And this will not have ANY impact on the applications we ship. Using such approach there could be solved a lot of things.

As about the coding, there are certain commands that are quite hard to implement and require a lot of attention from programmer. For example, late binding of VFP code to ActiveX object events. Use of VFPCOM.DLL takes some time from VFP developer. Why this could not be included into the VFP, but just use somethign external? Would like to know answers to this and similar questions...
Another reason to make a set of commands as a single new VFP command is a speed. C++ code is much more quick that the same algorithm written using VFP code. Is not it true? Was this ever discussed between MS and VFP community?


>>Incidentally, it might help public relations if someone from MS could could >open dialog about certain requests- for example, to explain why certain >requests might be unrealistic, logically impossible, too costly development->wise, or really just not a good idea.
>
>Erik, we've spent a fair amount of time recently consolidating the vast collection of our ERs into a common Foxwish database here at MSFT that allows us to truly evaluate them based on costs, risks and other factors. We're quickly approaching 1000 ERs, which is quite a bit when you think about it. I guess this product is far from mature <g>.
>
>We have a variety of sources including UT, Fox Wiki, Foxwish alias, Beta, etc. Consequently, there are a number of dupes, but we have setup the system to track these dupes as links in case there is relevant information in one of these linked records.
>
>One of our primary goals with the next version is to make it very customer driven, so there will be heavy emphasis in review of the ERs you guys and others have submitted.
>
>There are a lot of factors that go into the ERs we finally choose to implement. We try to find things that offer the biggest bang for the buck. If there are complicated features that would take our Dev team a long time to code with only limited appeal to a minority of our customers, then we may be less inclined to do that one. We also try to go after features which we think offer functionality that is not easily available through some other mechanism. This especially applies to convenience features. We may not be very interested in an ER for some language enhancement which merely consolidates several lines of code that you can already do today in VFP7. In fact, this is the type of feedback many of our beta sites have told us. Obviously, risk is always something to be concerned with.
>
>The team is still evaluating all our options for the next version, so everything is wide open at this point. Personally, I wouldn't mind focusing on features that have direct impact in the apps you ship, such as ERs in OOP, Data, Web, Form and Controls improvements. I guess I should prolly include reporting in the mix. The other thing I look for is creativity. Sure, its cool to copy what other products are doing especially if it works (e.g., IntelliSense). But it is also nice to have some uniqueness to our product (we love it when other teams come to us for advice on how to implement something we did first).
>
>As for a format to submit ERs, I think Steve Black posted some excellent guidelines on the Fox Wiki. It helps when you can provide real-world scenarios how the feature would be used. Another thing that is helpful is for ER feedback. If someone posts an ER, it is great to see feedback from others on this ER. Maybe some folks don't think it is such a good idea. We like to hear all opinions.
>
>Hope this is of help. Happy Trails....Randy