Exploring VB .Net from a VFP Perspective (Part I) (by John Koziol)
This is the first in a series of posts on VB. Net observations. It's not formal; it's just an online journal of things I found cool and weird coming from a VFP developer with 20 years of database language experience.
One of my tasks this past several weeks was to transfer product tests from a VFP application to a database in use by the rest of the Developer Division. I could have easily done this in VFP; as we Fox guys know, VFP is great for tossing data around.
However, I saw this as an excellent opportunity to get more comfortable with VS. Net and, specifically, VB .Net, which is the primary language the VS Data write tests in. I'd done some ad-hoc stuff up until now, and - of course - a lot of debugger work grabbing call stacks when VFP blew a rod. But to do this right, I was going to have to become very familiar with .Net classes and objects and the means of data access in .Net
It has always seemed to me that to understand a new programming language, one must first embrace the paradigms of the language - everything else is just grammar and syntax. So I started to play.....
One of the strangest things (to me) to get my brain wrapped around is that all variables are objects of various classes and have to be declared before they can be used. For example, in VFP we go:
nAmount = 17.50
And then we're on our merry way....in VB. Net, we can do this two ways:
Dim nAmount As New Double
nAmount = 17.50
Or....
Dim nAmount As Double = 17.50
Easy, huh? Now suppose you want to store that to a character variable (String in VB). In VFP:
cAmount = STR(nAmount)
We use the STR function to transform nAmount into a string and store in to cAmount. In VB we can do it two ways. The new .Net way is:
Dim cAmount As String = nAmount.ToString
You see? ToString is a method intrinsic to the Number Object. Kind of like when we want to refresh a Form object in VFP, we use frmMyForm.Refresh. The other way is to use the CSTR function, which has been around the language for a while:
Dim cAmount As String = CSTR(nAmount)
Anyway, there's a lot more to learn and more cool things to try. I'll post again in a few days with more observations.
Comments
Anonymous
February 10, 2005
Just nitpicking this before Paul Vick does -- CStr is an operator (like all the Cxxxx's, and DirectCast), not a function.Anonymous
February 10, 2005
I guess this is the first in a series to, once again, attempt to swoon VFP programmers into VB. It didn't work with VB6. What makes you think it will work now?
What needs to be demonstrated is that database apps can be developed faster, with greater performance, easier to maintain, less cost, and all that entails a better value to the customer using VB.NET instead of VFP.
Demonstrate all of the above instead of the string functions and maybe some of us will listen.Anonymous
February 10, 2005
Hi Vern,
I'm not attempting to swoon anyone into anything. As my VFP friends can attest to, I'm a diehard VFP developer. However, I'm not married to VFP to the point of excluding other tools from consideration.
There are some cases where a VFP solution makes the most sense. I totally agree with you that a VFP solution with local data may make the most sense for a client. OTOH, the .NET toolset offers a helluva lot. I'm just now starting to delve deep into it and all I am trying to do is share my experiences, not to convert the faithful.Anonymous
February 10, 2005
This is GREAT!
I am an old-timer who started using xBase with dBase II. I made the switch to FoxBase when it came out and have been in love with the product ever since. I will program in VFP till they turn out the lights but...
I realize that, for Microsoft there are certian economic and philosophical realities which collide with VFP and I have accepted that VFP may not always have the following to keep it alive. Whose fault that is is of no concern. I only want to understand the realities of the situation.
Learning VB.NET make a lot of sense to me. Whether I am aided in that endeavor by someone trying to 'swoon' me away from VFP is of little concern to me. I am interesting in learning and in using the best tool for the job.
I sat down and asked myself why I got into programming in the first place I did not know or love FoxPro then. The answer is that I love the hunt. I love creating things from nothing but an idea and a few electrons. The process of bringing a system into existence is one of the most wonderful experiences that I can imagine.
So, FoxPro, no mater how much I love it, and I do love it, is just a tool. It is not sacred. What is sacred, in some sense, is the drive inside me, inside all of us, to create. Anything that gets me to that end is good...
I wish that Microsoft would sponsor a site or wikki that fosters/mentors VFP programmers who are trying to learn any one of the .NET flavors. That would truely be great indeed!Anonymous
February 11, 2005
The comment has been removedAnonymous
February 11, 2005
There are a ton of good resources for information on VFP9 so practically anything I address in that regard is repetition.
As to VB vs. C# - There really isn't much difference from the .Net perspective; also, my group is under the VB umbrella so our testing tends to be mainly VB.Anonymous
February 11, 2005
This is even GREATER!
Maybe Microsoft would sponsor a site / wiki for Delphi programmers wanting to learn .NET. Or how about Python programmers wanting to learn .NET. I got it - how about COBOL programmers wanting to learn .NET.
Gimme a break. Anyone who WANTS to learn it will learn it no matter what programming decipline they come from.
I work as a contractor with 53 other contactors for a company who has some big projects. There are 14 VFP guys and the rest are Java programmers. NONE of us are learning .NET. NONE of us have the time to learn it even if we wanted to. As far as Management is concerned, .NET is not even on the radar.
Actually, I just now realized why MS wants us to learn .NET - it's a hard sell.Anonymous
February 12, 2005
The comment has been removedAnonymous
February 15, 2005
I made the move from VFP to VB.NET almost two years ago (having used VFP exclusivly for 6 years). All I can say is I cna't imagine going back. I was a die hard VFP fan, but after fully sinking my teeth into .NET, I can really enjoy it's power and flexability. There is no comparison, VFP feels like a legacy tachnology (and it is) compared to .NET. Flame on if you want, but I am more productive and can produce better applications in .NET. I encourage everyone to give it a good ammount of time. THere is a learning curve to be sure, but once you've gotten past it, you won't be able to look back.Anonymous
October 14, 2007
PingBack from http://foxpro.ntsl119.com/scr/archives/436Anonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=15282