Hi Rick,

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

I agree that it is a ground breaking enhancement rather than a groundbreaking new feature. However, having seen what you can do with it it is VERY goundbreaking if you compare it to the old one. Is there still a lot to be desired, sure... Personally when I see a mixture of VFPs report writer and Crystal Reports as the ultimate.

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

Agreed, the SQL enhancements are indeed quite substational. However there still is quite a bit to be desired. The VFP totally missed the issue with DELETED() records. They provided a binary index that is more like a two edge sword than a good solution. Watch what will happen when people upgrade their well working VFP8 applications to VFP9, having a large dataset and indexes with a FOR !DELETED() filter on it. Since those filters are now optimizable and this index will be used to filter out deleted() records, it is going to drag the whole indextag to the client for rushmore processing. A blunder of the 1st category.


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

As I did understand VFP has a lot of machine code in there which have to be taken care of. So a simple C++ recompile won't cut it.

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

Though I would apploud for that, I wonder how valuable that would be. Sure a CONVERT() function would be nice and a bringing them more closely by allowing the same syntax in both would be a good thing, but when doing large and complex SQL, VFP just won't cut it. Its rushmore optimizing engine is not advanced enough to handle such complex SQL on large datasets. In a current project I had to carefully redisign queries that took say 10 - 20 seconds to a fraction of a second. It all had to do in the ordering of the JOINs and processing them, something you have little control over and the engine is just not smart enough to figure it out itself.

In many cases it just pays of to split the SQL commands into two or more SQL commands to make it more efficient. Something that should not be the case.

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

Not sure what you mean by that.

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

Personally I rarely had to deal with unicode related problems. IF so, the STRCONV() function helped me out. Can you point out where UNICODE is a real problem currently

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

Well then we would have a VFP.NET language, hopefully not a too dramatic change from VFP as we currently know it. I do see that on the long term .NET is a better platform for a lot of reasons. Currently it is not up there yet to jump ship for me (and I assume a lot of other VFP developpers), but if we get a language that at least has all the strengths of VFP has I have no problem in upgrading my development platform. I'm perfectly aware what the VFP team has said about VFP.NET, but assuming that .NET will have more data centric features a la VFP, the disadvantages of .NET will decrease to a point where it simply does not make sence to continue development of VFP anymore. So I see that VFP will either merge into another language or simply will the discontinued at some point. This might be years away from now, esspecially since I feel there is still enough reason to use the FOX, but this will change at some point in the future.

If we as the VFP community have the opportunity to have some influence in the direction VFP is going, I'd say that we should try to go into a direction where we as VFP developers don't have lot of problems in jumping ship, forcing ourselfs into a methology that does not fit with the data centric approach of VFP. Currently the GAP between .NET and VFP is too huge IMO. Take yourself as an example and look at the experience in learning .NET. Sure we all have to learn differences, but you can't tell me that ADO.NET is an improvement over VFPs local data engine. You had to workarround the problems you could solve so easily in VFP. Of course I can hear you say things about portability of data with ADO.NET, That is absolutely true, but that is about the only thing I can think about.

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

That is absolutely true. I'm not sure how long the VS.NET cycles are (36 months or so ?), but I really like the 22 months release cycle of VFP last couple releases.

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

Yep

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

Well, I'm not asking for every control, Better one or two, than none at all IMO. Get me the treeview first, the flexgrid and listview can wait a little :)

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

Sad. There are still a lot of development languages doing ActiveX, and a lot of vendors still are doing and maintaining the ActiveX components I frequently use and only introducing the .NET variants (often a limited functional version) right now. A lot of those vendors do not like to be on the bleeding edge either it seems.

>>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'm saying that VFP should enable the features needed to write such frameworks. BTW there is no real difference between developping application in a development language like VFP (4GL) and a development framework (5GL?) other than that in a framework you more specify WHAT to do, rather than HOW to do it.

In a sense I'd like to see VFP steering more towards 5GL, beeing a powerfull development platform with high quality RAD features. .NET currently is still a few steps behind VFP (You generally have to write more code to do the same).

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

Yes, I agree and understand. I really apreciate the stunning results they achieved with VFP9 with such a small team.

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

I am not screaming here, I was just reacting on your assesment of VFP9 not having ground breaking features, which I disagree somewhat with. I find it is amazing what the VFP Team has accomplished in a short time.

Walter,