>>Patrick,
>> I do Database Apps almost exclusively, lol. ADO.Net took a bit of getting used to but it wasn't too bad. To be honest, i always detested the .dbf DB system. I love the power of the xbase languages but thier data contaners always left something to be desired imo. For the last few years my vfp apps always had a different back end, normally Sql Server. I also "conditioned" myself away from using ad hoc queries during this time, to me having middle tier biz objects calling stored procs from Sql Server was usually a much better paradigm. Since I went into it with that mindset the transition wasn't that bad.
>>
>> I still believe the biggest hurdles for VFP developers to overcome in switching to .net are conceptual. Syntax is syntax, "it ain't rocket science" but switching how you visualize code flow and instantiation is. Going pure OO is tough. C# doesnt leave you a choice, all code pretty much lives in methods. Sometimes i do miss being able to write procedural functions or blocks of code but the trade off is a good one. Especially if you are an architecture and design fanatic like I am. I want to kill anytime i see more code in a button's click event than just a simple method call. I know I am a bit pickier than most there is a method to my madness.
>>
>> Basically how you use vfp is the biggest factor in the difficulty of transitioning. LINQ also looks like it is going to close in alot of the DML gaps for .net. It has me pretty hot and bothered. I can't wait to rewrite 100's of business objects that work great just to leverage a coller technology, lol.
>
>
>If a Click() event is just a method call, what is accomplished other than the addition of another level in the call stack? If it isn't reusable functionality I see no point in breaking it out.

Neither do I, but many seem to.

To me it's easy enough, once any such code is found to be reuseable, to turn it into a method.