I was referring to "variables"; not class "members".

By "declaring" one's "variables" in VFP, I simply meant that one should use a PRIVATE or LOCAL first, instead of simply i = 1 + ..., for example, "somewhere" in your code.

In that way, it is easier to translate a statement like

PRIVATE i 

to

int i;

than hunting thru your (old) VFP code and trying to figure out where you should put an initial declare of a variable.

The C# "access modifiers" are pretty well the same as the ones used in VFP classes and translating at that level is less of a problem.

>One little correction to your statements.
>
>There is a default access modifier in C# (public, private, protected, internal). The default is private.
>
>Declaring the variables type is the important part that is different.
>
>PF
>
>>Get a little familiar with the .Net framework and the C# language (keep a book or 2 in the WC). A book on building applications in .Net would be good.
>>
>>.Net apps are typically multi-tier; you should be thinking of your VFP app in the same way.
>>
>>.Net needs a database back-end and has no support for a "local cursor". This implies you should be giving lots of thought to stored procedures ... whether in VFP (DBC), SQL Server or whatever.
>>
>>With C#, you need to explicitly declare your "variables"; get in the habit of doing the same with VFP (PRIVATE, LOCAL).
>>
>>In .NET/C# "everything is an object"; make your VFP app fully object oriented. Be sure to separate the presentation layer from the business layer ("jobs", report generation). Think of using XML to communicate with "remote objects".
>>
>>If you know VFP now, consider the fact that it will be some time before you can be truely productive in .NET.
>>
>>At the same time, you can move ahead with VFP now and keep an eye on the future my structuring your app and code in such a way that it will be so much "pseudo-code" if and when you decide to port it to .Net (in whole or in part).
>>
>>>I'm sure this debate has been had a thousand times, and I've always been secure in our descsion way back in the days of VFP3 and Delphi1 That VFP was the ideal langauge for us.... BUT.....
>>>
>>>I recently chatted to a fellow developer who has a) been to the Foxpro Devcon and had b) come away feeling that anything new he did had to be in .NET because Foxpro was on its way out, maybe not for a year or three but the "writting was on the wall".
>>>
>>>Since I was not at DevCon I can't say how he reached this conclusion, but as we are just about to start a whole new project with no history, should we been looking at .NET instead of VFP?
>>>
>>>I know many of you will say "that depends on the application" but once you start down a track it's not often able to change. Initially this will be a datacentric application on standalone PC's or small networks. But who knows? Web Access?, hand helds? if it's successfull there may be many possibilities and a re-write would not be invisaged in the next 5 years. So is the fox slowing down? should we be in the .NET?
>>>
>>>
>>>Gary Williams