Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
What does .NET offer the VFP doesn't
Message
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Miscellaneous
Thread ID:
00672445
Message ID:
00672601
Views:
14
Isabel,

Here's are a few of the differences to consider:

* The ability to create multi-threaded applications (you can't do this in VFP).

* Strongly typed languages – You can consider strong typing a plus or a minus, but after using both strong and weakly typed languages, I definitely consider strong typing a plus. Visual FoxPro’s weak typing may give you more “flexibility”, but in the final analysis, weak typing lets a lot of bugs go unnoticed until run time. The bad part of this is that it may be the end user who runs the code and finds the bug rather than your development team! Strong typing allows the compiler to catch many of these errors at compile time, and enforces good programming practices.

* Better object-orientation in .NET languages. Visual FoxPro’s object model has 35 different classes—all of which are peers. The .NET Framework has over 2000 hierarchy of classes (this is where you’ll find the real learning curve!).

You can simulate some of .NET’s OO features in VFP, such as abstract classes, but these features are built into .NET and are enforced by the compiler. For example, you can specify that classes are abstract (cannot be instantiated), or sealed (cannot be inherited). In both VFP and the .NET languages you can specify that a class’s visibility is public, protected, and private--.NET allows the extra visibility setting of "internal"—which means that the class can only be accessed by other classes in the same project.

Visual FoxPro 7 has support for COM interfaces—which is great, but .NET languages have far better support for interfaces that do not require the use of components.

In Visual FoxPro if you have optional parameters, you need to add some "messy" code that checks for the values of parameters and acts accordingly. In .NET languages, you can create overloaded methods—methods with the same name but different parameters. The correct method is called on an object based on the number and type of parameters that are passed to it.

* Automatic garbage collection. Did you ever have a Visual FoxPro application that gets slower and slower the longer you run it? This is usually caused by memory leaks—areas of memory that are never freed up. As your machine continues to lose memory over time, your application runs more slowly. In .NET, automatic garbage collection takes away many of these headaches. It runs in the background and frees up memory on the heap at specified intervals.

* Cross-language compatibility without an Interop layer. I’ve done a lot of COM programming over the years and, although it’s amazing how well it can work when things go well, it’s a royal pain in the neck—and it’s slow due do the conversion of data types between languages. .NET solves this problem by providing language interoperability by means of its Intermediate Language (IL). This interoperability allows a class written in one language to be subclassed in another language; classes can contain instances of classes written in a different .NET language and call its methods directly; the Visual Studio .NET debugger can step between code written in different languages.

* Zero impact installation – This is most apparent when it comes to installing COM components versus .NET components on a machine. COM components must be registered in the Windows Registry--.NET components do not. I teach quite a few classes in both VFP and .NET and in every class I have taught that required students to install COM components on their computer, there are always a handful of students who were not able to do so because of “issues” with their Registry. In the .NET classes I’ve taught we simply copy the components to the students machine and they just work!

* Operating-system-agnostic access to OS functionality. In Visual FoxPro, I need to use the Windows API to get at some lower-level operating system functionality. In .NET, I use the .NET Framework classes which provide a layer of separation between my code and the operating system—in the future, this can allow me to move my application to a non-Windows platform. When I use the Windows API, I’m hard-coding to Windows.

* A single learning curve for Windows desktop and Web applications. Microsoft has done a great job making the development environments for Windows and Web applications very similar. Once you learn how to create Windows applications using VS.NET, you’ve climbed most of the learning curve for building Web applications. ASP.NET is everything that ASP is not!

* .NET has very strong XML capabilities. In addition, it’s incredibly easy to build schemas and XML files with the design tools available in VS.NET (we get lots of "oohs" and "ahs" in class when I show these.

I hope this helps!
Kevin McNeish
Eight-Time .NET MVP
VFP and iOS Author, Speaker & Trainer
Oak Leaf Enterprises, Inc.
Chief Architect, MM Framework
http://www.oakleafsd.com
Previous
Reply
Map
View

Click here to load this message in the networking platform