When are you going to write a book, Bonnie? Serious question. You have the knowledge and you have a nice writing style.

I'll buy it. So there, you've got one sale already.

>Lots of good advice here, John.
>
>#7 (bad example code everywhere on the web) drives me nuts. I see plenty of stuff that seldom contains the correct way to do anything and lots of time is just plain wrong.
>
>Ditto to your point about the "auto-magic" stuff. It ain't all that magical if you ask me. <g>
>
>~~Bonnie
>
>
>
>
>>Good points,Tracy.
>>
>>To me, the problem with focusing on data handling is that there are a plethora of ways to access data in .Net and the syntax and structure for any of them is a bit counter-intuitive to the Fox way. In that respect, the "auto-magic" stuff that happens when in the forms designer in .NET obfuscates what's actually happening - makingit more difficult to understand how to hand-wire.
>>
>>>>Folks,
>>>>
>>>>I'm going to keep this simple. Early last year I went on haitus as a test engineer and moved back into the developer world. I was fortunate that I was hired by a company that I had already worked with years ago and they re-hired me by past reputation and were willing to overlook the fact that my last relevent programming experience was .Net 1,0 and sketchy with that and needed time to ramp-up.
>>>>
>>>>I know a lot of you don't have that advantage and employers are looking for immediately usable skills. Especially in this economy. So I am going to suggest a series of steps to gain a foundation that you can use to get to where you need to be. I'm assuming that you're willing to bust butt on your own time while doing what you have to do to pay the bills.
>>>>
>>>>Also, I don't want to take anything away from the EDS or Oak Leaf bootcamps and training. My only concern with those is that they go a mile wide but an inch deep. I'm not clear what marketable skills you gain with practical application.
>>>>
>>>>So here are the lessons I've learned and my suggestions. They are not all-inclusive. They are not expert. They are just what has helped me and the pitfalls I've run into and how you can mitigate them.
>>>>
>>>>1. Language is irrelevent when at the ground-level. Walk away from the C# versus VB argument. From the VFP perspective, VB.NET is easier to understand and 99% as functional. What you'll find as you get more proficient is that it's just as easier to understand or code in either. So focus on VB.Net. Once you understand VB code without a reference manual, C# will make sense and you'll find yourself pretty much equally adept at either.
>>>>
>>>>2. Get foundational literature. Anything by Charles Petzold works for me (the Programming Windows series, for example). I found myself using old functions like Str() because I could when I should have been thinking x.ToString. I had to make a mental effort to break that pattern and it really pays off as you get more into the complex Framework types.
>>>>
>>>>3. Get a buddy. You are going to have, from a .NET developers perspective, stupid questions. It's inevitable. Have someone or someones who are willing to answer your seemingly dumb questions without issue.
>>>>
>>>>4. Ignore the bleeding edge. If building a basic ASP.NET page befuddles you, you have no business looking at Silverlight or cloud computing. Get confident in the basics and it'll add tremendously to your understanding of the other stuff.
>>>>
>>>>5. Set a functional goal. If an employer is not already paying you to do so, finf something simple worth doing and code your first project towards that. Or convert your simplest VFP app.
>>>>
>>>>6. Apply Extreme Programming (XP) principles. Your first app may work but your code will suck. So what? One ot the tenets to XP is to refactor until good. Once something works, refactor towards best practices. If you break it,so what? Revert to working code.
>>>>
>>>>7. Do not assume examples on the Web are canon, In the old Fox world, for the most part, people only posted code that they knew worked. Not so these days - there is a lot of crap out there. Take the ideas to heart as presented but be very leery of the code - especially if it's using Northwind or AdventureWorks since those dbs seem to be the refuges of the semi-competent.
>>>>
>>>>8. Take pride of ownership, If you're a good VFP developer you will be a good .NET developer. Be proud of making things that work no matter how minor. You'll get better because if you've already mastered VFP then .NET is just a different syntax.
>>>>
>>>>9. Give it time. Don't get frustrated, Think about how long it took you to master what you already know and expect another learning curve here as well. Not all skills are transportable to .NET from VFP but common sense is.
>>>>
>>>>Wow. Guess I was long-winded, huh? For those of you who have made the transition, please add additional pointers? For those of you who wish to make the transition, please post questions or concerns.
>>>>
>>>>A rising tide floats all boats,huh?
>>>
>>>Great recommendations! My notes: #3 can be accomplished here on the UT (although it shouldn't be in place of a coding buddy) as long as the poster develops a thick skin and is capable of ignoring those who only respond to complain about the very basic questions being posted (it's a shame when that happens). When starting out in any new tool, there are always very basic questions. I hate to admit it, but there are other forums more helpful in supporting those starting out and they are easy to find with a simple google search. #2 is a great recommendation, and I think a good book on it is a great idea, but it might be too much for someone to focus on that in their very first steps. They might be able to refer to it as they go along or return to it after some practice with using the language, but they need to try the basics first before they get submerged in the foundation and get overwhelmed. #1 For me, C# was easier to understand because I had worked with Delphi and C previously. Also, the choice was moot for me because the language we would use was decided by others so I switched and focused on it instead (I started with C#, switched to vb.net, and then returned to C# and I don't recommend that to anyone else in the beginning learning stages - pick one and use it until you are comfortable with it).
>>>
>>>While all your suggestions really are terrific, I'm not so sure you are representative of the typical VFP developer switching to .net :o) I've met many VFP developers who have never worked with separate tiers or even just business classes and some who have never stepped outside of their comfort zone (working with tables). Some have never had to interface with other tools or products or even touched reading/writing xml or pushing data to pdfs, let alone web services etc. Those who have never done that before might have an easier time if they focus on basic data handling first and then look at the design patterns later. I may be wrong about that (and it wouldn't surprise me because I am wrong quite often), but I think some things might make the learning curve steeper than it needs to be and end up being too daunting of a task for some.