>Hi George,
>
>snip
>
>Those are the kinds of "choices" offered up when someone really doesn't want to do something about a problem - like the public services Administrator who always picks on 'the peoples' favourite programs when cost cuts are threatened. It truly is the lazy person's way out of a problem.

First, it's not exactly clear what the "problem" is. If it's VFP's control's not being real windows controls and the choice between have "real" one's and ease of binding them to data, consider the following: If it could be done, then MS could do the same thing for its other tools (read VB). Given that it would be a highly desirable feature for VB, you'd think that if it could be done, then they'd do it. You want standard windows controls? Fine, use the MS Forms controls that come with VFP 6.

Even doing that wouldn't solve the ActiveX container problems without changes to the way VFP handles windows message services. VFP's main currently has to handle the messages so that things like re-drawing the controls is properly handled.

You should accept that if MS would make the controls real windows objects, they would. Afterall, it would be in their own best interest to do so. It would both improve the product, and probably cut their costs. Like it or not MS, is in business to make money.

As for the API stuff, about all you can't access from directly VFP are the functions that require callbacks. Again, it's the difference in messaging.

Bottom line is that the analogy doesn't apply.


>Hell, FP got famous doing what others said couldn't be done! VFP actually delivered a OOP developers tool against strong odds.

"...FP got famous doing what others said couldn't be done"? Nope, Fox got famous for being the fastest and best data manipulation tool on the desktop. VFP wasn't the first OOP developers tool, for data or otherwise. Why then was it "against strong odds"? Because people thought it couldn't be done or they thought that MS wouldn't do it?

>The point is, "miracles" CAN be accomplished when one's heart is in it. And what you mention are hardly "miracles"!
>
>Where there's a will, there's a way. In the case of VFP, there is no (demonstrated) will to accomplish these things.

Well, if you accept what I said before this doesn't deserve addressing. If you don't then you'd have to convince me that, for whatever reason, MS simply isn't interested in improving their product line. Unfortunately, there's "no sale" there since the company's history runs directly contrary to that.

>As to the original subject of this thread, the VFP "Future Directions" paper has been updated and now specifically mentions '1 and 2 tier'. That could be a great thing inasmuch as the thread title is concerned, but frankly I'll wait to see something in real life before I believe that. Since it appears that many of the known problems in GUI functionality of VFP 5 remain in VFP 6, I take that as further "proof" that the VFP Team's work on the GUI aspects of VFP is severely lacking. There has been no indication that this is about to change.

Jim, if I were a member of the Fox team, I'd be insulted by this and what you've said before. The implication is that they lack the will or that their skills are subpar and so on. Further, what you're saying is that they are delibertly making the product more difficult to deal with, otherwise they'd solve the problem. To expand on what I said earlier, if they solved the problem, their work overall would be easier. There'd be no convuluted messaging system to maintain. Given the implications of the solution, don't you think that if it could be solved, it would? Aadditionally, direct communication I've had with Randy Brown leads me to believe that the Fox team is both dedicated and determined in it's efforts to improve the product. My conclusion is based on personal experience. Your's on pure speculation.

>I can't, for instance, recollect anyone here crying for 64-bit VFP. Yet you suggest that that is on the way. The same can be said for VFP 6's OOPification of the PROJECT, of its Component Gallery and of its Foundation Classes.

ell, 64 bit Windows is on the way. The specs are published and available in the MSDN library. To think that 64 bit versions of the development tools wouldn't be implemented accordingly is absurd. No one has to "cry" for it, it's all part of product development and improvement.

As for the rest, all of what you've mentioned have led to the product being improved. The Project hooks can increase productivity. The Component Gallery and the FFC means that new users are more productive from the moment they open the box. Without new developers, VFP is dead, as any other developerment tool would be, as a product.

>People here can offer any number of reasons why things are the way they are. I still am anxious to hear reasoning from the mouth of MS/VFP Team itself.

Well, maybe you ought to take it up with Randy Brown, or better yet, maybe he'll respond when he reads yours.