Wiki Home

Why VFP Needs Frameworks

Namespace: WIN_COM_API
Problems in VFP that Frameworks make quick use of.
This is an important topic for the Visual FoxPro Wiki. Currently, this article is incomplete, and it would be cool to expand it. If you know anything about Why VFP Needs Frameworks, please consider editing the topic and sharing your knowledge.

I'd be very interested in a wiki page that lists the elements of the "poorly designed base classes" and the "incomplete features in the language itself" and by that I assume you mean VFP, and how frameworks and toolkits actually help (or don't) in this area, and how a box full of OEM features makes various needs go away, or not go away.

This is just a rough copy, I've got much more to say, and many more examples, but I'm going to start here. Eventually I want to take this argument to another level: while VFP developers beleive inheritance is essential (because of the shortcomings in VFP), in .NET it will be an occasionally used feature.

Problems in VFP that Frameworks make quick use of.

Creating an EXE

1. You have to create a PRG
2. Include it in your project
3. Set that PRG as Main
6. Put some caption stuff in a Config.FPW
7. Compile and Run
In .NET, you only need to do Step 7.
Um, if you only do step 7 in .Net you've got nothing!

And if you do all seven steps in VFP, ... you've still got nothing. My point: set any non Fox user infront of Fox and ask him to compile a working EXE, they're going to spend hours looking through docs or samples. In .NET, once they have their project up, the can hit F5 and they're off an running. -- Mike Helland

All I can say is that you haven't worked in .Net enough to create a class library similar to the VFP libraries out there.

As people write .Net apps, they will see that much of the code they write is the same old, same old...

1. Create a connection
2. Send a command
3. Etc...

1. Display a form
2. Maintain a collectin of forms
3. Write code to maintain related forms
4. Write menu handling code
etc, etc ....

This will cause someone to write a class to encapsulate this stuff. I think the business frameworks that come out of .Net will be very similary in structure. However, their implementations will be much different.

Compile What? A project? And what's in the project if you don't do step 2? And, why does any of this matter? Is it complicated? Does it have to be done more than once per application? Ray Kirk

Are you talking about Fox or .NET here? And yes, it is complicated. To create a windows application that runs but does nothing takes a developer new to Fox hours, if not longer. Unless they use a framework... which is my overall point. -- Mike Helland

Create a database agnostic data tier

Most VFP Frameworks will provide some sort of object model to act as the data tier so that applications can be quickly scaled data-wise. .NET has ADO.NET built in.
ADO.NET is not a data tier. It is a data ENGINE. To see the difference, look at Doug Hennig 's excellent article on n-tier development on the Stonefield web page. Ray Kirk
This isn't quite true. When I have time, and my arguments are developed, we'll re-address this. -- Mike Helland

VFP also has its own built-in data abstraction: Remote Views. Sure, not everyone likes them, but that doesn't change the fact that they can be used without a third party framework. I think the point is moot anyway. With .NET, I expect developers to create data objects so they don't have to type the same code over and over. -- Joel Leach

Error Handling

In order to implement your own error handler in a VFP app, I recommend you read the large white paper by Doug Hennig. In a .NET app, structured error handling is simple, and can be used with your application logic, as opposed to outside of it in a complex and twisted error handler.
My understanding of the .net error handler is that it is implemented via error events on the base classes. How is this different from VFP? Ray Kirk
Exception handling uses TRY...CATCH...FINALLY in .NET that runs inline with your code, you don't need any error handling on top of that. -- Mike Helland
I like .NET's exception handling, especially the way the unhandled exceptions get sent up the call stack. I'm not sure if you can do this in VFP. However, Doug's article is refering to sending unhandled errors up the containership hierarchy. To do that in .NET, I *think* you'll need to use a similar method. Also, I assume you'll want some kind of global handler in your main program for dealing with unhandled exceptions. This is something that a third party framework provides, or do you use .NET's default handling? -- Joel Leach

Please clarify: Are you saying inheritance isn't needed in .NET development, or that programmers simply won't use it out of apathy? How will object behaviors be changed in a large scale application? Copy & paste? Isn't it up to us as developers to create the abstraction layer as a buffer between our objects and the .NET "base" classes? Hence, a "real" framework. -- Randy Jean

I'm not saying it isn't needed. I'm saying that it will be used far less than our typical VFP applications use inheritance. A couple of reasons for this, but besides the one I've already mentioned (we need to use inheritance to overcome VFP designs), the main reason is delegation. I'm finding where I've been used to inheritance in Fox, delegation in .NET is much cleaner. -- Mike Helland

I think this depends on how loosely coupled your classes are. I use VFE which incorporates an abstract factory, full separation of tiers, etc. delegation is used where appropriate and I'm free to use my own "custom" classes wherever I see fit. Sure, it's a third party framework, but I fail to see what's wrong with that if it helps me to provide winning solutions to my clients business problems. In my opinion, it's a steal. -- Randy Jean

Sorry if I gave you the wrong impression, but there's nothing wrong with that. Thats not what my point is here. -- Mike Helland

No prob. I'll be the first to admit that I have not spent the time needed to get a grasp on .NET - I just went through the 1.5 hour VS.NET install on my laptop but still have not been motivated enough to spend my "free time" on doing anything with it. One thing I will say is that one not need to look far for .NET samples and info. MS has an incredible amount right in VS.NET as well as their web site. Frankly, I find the amount of information on the subject overwhelming. -- Randy Jean

The current .NET Show looks pretty interesting:

I appreciate your comments here, Randy, but like I said, I'll clarify this with better arguments when I have time. For now, I just want to look at VFP and why its use of Frameworks and inheritance are essential.

I would answer you by pointing out that .NET is a framework. VFP does not come with a framework, ok it does but the framework that is included is not really good for robust apps. I would also propose that it is NOT required to use inheritance in VFP, it is strongly recommended to create an abstraction layer of classes between yours and the VFP base classes, but it is NOT required to do so. IMHO, it is a waste of time to argue the differences between VFP and .NET as they are very different things. VFP is a data centric development language and .NET is a framework that can be used by multiple different languages for applications that run the full range of everything, that is, not necessarily data centric. -- Jim BoothOffsite link to

This topic has turned into VFPversusDotNet. Can we refactor it please to get back on topic?

Category Frameworks Category Vfp Wish Lists Category Development Environments Category Third Party Tools
( Topic last updated: 2005.08.22 06:21:24 AM )