Compartilhar via

Exploring VB .Net from a VFP Perspective (Part II) (by John Koziol)

  • Artigo

Sheesh.  Some of the feedback I'm getting on this series makes me feel like a traitor to the Visual FoxPro community. Nothing could be further from the truth; I love the VFP community and I am a staunch supporter of VFP and have been for many years. I think my contributions speak for themselves (harrumph! - lol).

I'm coming to the conclusion that VB .Net in itself isn't all that difficult and most VFP developers could adjust to the language in a short time. You have to get used to the idea of constructors and hard typing of objects and variables in that we can't just spuriously assign a value or object to "x" implicitly. I think I covered a little of that in my last post.

What's staggeringly complex is the .Net framework itself. I know that most of you have heard the phrase ".Net Framework" and, maybe, been a little in the dark about what that meant. Well, essentially, think of the framework as classlibs installed into your system. In VFP terms: Each classlib belongs to a library that .Net refers to as a "namespace". When the framework is installed, some binaries are installed in the Windows directory that allow for the basic namespaces, for example "System."

You can enhance the number of objects available by including external references into your .Net project. For example, I am working with a DLL that exposes a bunch of methods and properties to my VB app once I add the reference to my project.  This is akin to adding a classlib to your VFP project.

Anyhow, I'm convinced that the winning combination for Fox people to learn .Net is to muck around with the VB or C# language with small tasks, but to really focus on the .Net framework and what it can do for you.

It's not that hard. Really.

Sorry, no code samples this time as I'm mired in fixing an obsolete test driver. Which is actually teaching me a lot, but nothing I can synthesize into absolutes at this time. Duty calls.

I'll get more to y'all when I can.  Meanwhile, there are a few VFP to .Net books out there that are worthwhile. While I'm constrained in giving recommendations to 3rd party products, I'll give you a hint:  One is by Kevin M. and one is by Les P.  Figure it out.

Comments

  • Anonymous
    February 15, 2005
    Hi John; no, of course you're not a traitor. I'm with you that VFP programmers should also have knowledge of other tools. And if that's only just for realizing how comfortable and easy the FoxPro environment is! Without the experience of how much you loose, if you switch to another development system, you cannot value the really feature-rich, stable and proven environment of VFP.

    The main reason for the sensitivity of the FoxPro community against every mention of DotNet is the really amazing ignorance of Microsoft for their customer needs. DotNet is a cool development system, IF you are in the midrange or enterprise level. But it's an absolute overkill for anything smaller. There are millions of customers in the small business area, which are best served with a tool like FoxPro. But as long as MS spends Millions of Dollars for DotNet only and not one Cent for VFP: what do you expect? If your needs are constantly ignored, but you get constantly reminded that DotNet is the way to go, even if it can't solve your customers needs like FoxPro could?

  • Anonymous
    February 17, 2005
    Thanks, John (and yag, etc.) Stay the course. Rememeber that the majority of us love to get this kind of info and the vocal minority, well they will do their thing no matter what, right? :)
  • Anonymous
    February 17, 2005
    The comment has been removed
  • Anonymous
    March 05, 2005
    >> At some time in your past, you moved to VFP from something else.

    Yeah, I moved from dBASE II. <lol>

    Then moved to dBASE III Plus, FoxBASE+, and then FoxPro.