Well put James..

There really is nothing to fear...except fear it self...< bg >.

Here is a recipe for disaster: Take a VFP mindset and apply to the next tool you learn. No doubt, most if not all will fail.

Why?

Because I failed.

I realized that I could not take a VFP mindset to VB. Although, it took me about 2 years to finally figure this out. I tried in vein to put the square peg in the round hole.

I then realized that what I learned using VFP was not nearly as important as what I had learned in general. If I stuck to concepts and methodologies, I figured I might then have a chance.

Take inheritance for example....

To many, this is the achilles heel of VB. Try and implement inheritance, even similar to how it is in VFP, and you will quickly become frustrated.

To succeed, one must first understand what inheritance does, not so much how it is implemented in VFP. And there lies the issue...

The knowledge that people have aquired in the use of Fox have tightly coupled that knowledge in a Fox implementation.

Stay with me here...

As funny as it seems, folks that have learned the art of OO, did not apply it to Fox itself. Yes, they may have applied the craft in the applications they have produced, but what about the tool itself.

What must be done........


We must decouple the knowledge from the tool....


This is not to say that general theory in a vacuum is good either. It still needs to be applied. Certainly, there is a fine line...

With respect to inheritance, I found that if I first understood what inheritance does, and then look at it from VB's terms, then I had a chance at survival. In VB, they key is delegation.

Let me explain...

In VFP, lets say you have a button on a form that saves data. No doubt, there are all kinds of implementations of this in VFP apps around the world. Some folks may have used inheritance to inherit calls to a VFP class that actually does the work. Others may have bound the logic in the UI, still using inheritance. They common denominator of course is inheritance.

In VB, how would you accomplish the same task? They key is delegation.

OK, I have a form with a button that needs to save data. The save process is very generic. Yet, I don't have inheritance to help me here. What I do have is a dataclass of sorts that has the ability to save data. In a call, I could have the button send an instance of a data object to a save method and have it do the work. The data object in this case is a member of the form. Believe it or not, this is a case where lack of containership is nice.

Let's say that the name of the data object was called oData. In a form, I could reference the member like this: me.oData. Or, I could just reference it as oData. And, in the button, all I need do is reference it as oData.

We have come up with a way of having having behavior objects in VB that sit and wait for something to do. A button on a form that either adds, deletes, edits, saves , or cancels changes to data calls the same object.

The key to take from this is that while it is not inheritance, the ends are the same. There is next to no duplicated code. Through the use of ActiveX controls, I could create a situation where there is zero duplicated code...

Again James, the key is to first decouple the knowledge from your knowledge of VFP. Then, look at things on VB's terms and reconcile the two. Even if it is something else like C++, Delphi, or whatever, you will need to do the same thing.

Best of luck!!







>John,
>
>I consider myself a fairly experienced VFP developer. I've worked on some big projects and have paid my dues. I've invested a lot of time and effort into learning my craft. It hasn't been easy, and the thought of letting go of it to "embrace the enemy", so to speak, scares the hell out of me. I know I have what it takes to put together a faily solid application with VFP. I don't know where to start with VB.
>
>I, too, was in denial for a long time, but it's impossible to suppress the truth anymore. My skills are quickly becoming outdated, and I had better start learning new ones if I want to stay employed. Actually, now I look at it as an adventure, but I'm sure going to miss that comfort level of knowing VFP like I do...