>I'm not sure what you mean with ground breaking. Personally I find the new report write quite ground breaking. And there have been other request for ground breaking enhancements.

It all depends on perspective. It's still an incremental enhancement, especially if you look at the fact that to really use the new report engine you need to build on top of it. Yes it is very cool and I think VFP 9 is a great upgrade - many of the things are more like core feature updates like the new (quite substantial) SQL enhancements, improved support for binary types etc. which I actually think is what the product needed.

>- Going 64 bit
>- Having a server component for VFP, while not losing the xBase commands
>- ANSI SQL - 92 compliance (as much as possible)
>- Creating events and better support for API's

You won't get arguments from me on those (although 64 bit is questionable and probably will be provided anyway once the MS C++ compilers start spitting out 64 bit code more easily).

VFP 9 has made significant steps in teh ANSI SQL compliance. You'll likely see more fo that in future versions.

Then again most people who use VFP don't pay attention to that anyway - taking advantage of UDFs() etc. because it's so easy to do this in VFP with such a rich data language at your hand.

Along the same lines I'd vote for better Unicode support especially in the data engine.

>- Better integration or melding into .NET without losing the local data engine

Well, this has been discussed and more or less dismissed. While I coudl see this working it would be a major undertaking and likely result in losing VFP as you know it know for good. Keeping the local data engine and still be able to take advantage of native managed support for data (ie. databinding etc.) would be very tough.

And worse you'd be straddled with two different data access mechanisms.

And if the data engine goes there's not enough left to leave you with a VFP language. Beyond that what does VFP bring to the party?

And you'd strap the VFP team onto the .NET juggernaut for release cycles.

I'm not sure that this provide anything truly useful other than getting VFP even more lost in the shuffle. I compare this to the mistake of putting Visual FoxPro into Visual Studio 6.0. Remember that nightmare? Having to install VS to install VFP? Having to wait for VS SPs to ship for any updates etc.

There may be some value there, but compared to other core features to VFP this would - IMHO - be a very bad use of the limited resources that the VFP team has.

>- Native Treeviews and flexgrids (in stead of the VS6 ones, which dont use themes and are pretty simplistic in many ways) because the VFP team always has been good at implementing user controls.

Yeah, me too. I've asked for this on many occasions, and was told there was some consideration of taking over those controls and customizing them. I actually talked to Randy about this last week when he was here on Maui.

But again, here we have an issue where you're talking about system components. If you go down this path people will want (and actually need) eveyrthing else fixed as well. They'll fix the treeview and ListView, and then people will want the RTF control, and FlexGrid and Slider and etc. These are complex controls and that's not really VFP's job. Fixing for Themes would be a pretty easy fix if source is available.

I would like to see this too, but this has been the realm of ACtiveX control vendors. Of course, that's gone now that these vendors have mostly moved on
to .NET selling their outdated ActiveX controls and not likely updating them much.


>However, the best ground breaking thing would be to enable VFP to make truly data driven applications such as ERP/ERM applications in which the application itself is a database. VFP already has much in place on order to do that, but minor essectial things are missing, like running classes and reports from cursors so you can create applications without even to compile an EXE file (only the components are compiled in the background).

I don't think this is a spec for a development tool. This sounds like a framework or add-on, not the job of a development tool. VFP is more data driven than most tools as it is with all the designers based on data files that can be directly modified and created.


>I recognize that not all wishes are realistic, and currently even I am more concerned about instability, bugs and other less obvious problems in the product than about new features. VFP currently supports about enough to write very sophisicated programs.

>However there are some enhancements that would be most welcome. Not really ground breaking, but very usefull.
>
>- Hide pages on a pageframe
>- Easily accessing a cursor in another datasession, i.e copy one cursor to another in another datasession. Though I could use XML, its waaaayyyyy to slow.
>- Better RI, I offered TaxRI to include in VFP9, but they refused.

Again, you won't get an argument from me that aren't lots of little things that could use improvements. And I think many of these kinds of things will be addressed in future versions just as there were many in this release.

The problem is that there are limited resources. Sure, if there were unlimited resources we could all think of 10 or 20 'vital' enhancements. But the reality is that hte VFP team is small and has to limit what can be accomplished.

We can scream and yell about this as much as we want but that's what it is...