>>Interesting that all three of us tend to use hungarian notation for UI controls - and your point re: Intellisense is a good one. Not sure I go along with the 'm_' part though (definitely smacks of the VFP fieldname/variable name connotation) :-}
>
>Here's why I use "m_" for private/protected members that I intend to expose as properties:
>
>1) I got used to doing that in the old 1.1 days, before "automatic" properties came along. And, to be honest, I haven't really "adopted" automatic properties much because I don't like to "mix-and-match" the two syntaxes. Sure, they're convenient for when you have nothing in your getters/setters, but if you do then you have to revert to using the original syntax.

I'm quite happy using them - code looks cleaner. But, since the compiler creates it's own private variable under the hood I suspect that defining your own and accessing that directly within the class will be more efficient than always having to go thru the public property?

>
>2) I don't like the alternative, which is using casing. Too hard to make the distinction between member and property that way (IMHO).
>
>private bool isOK;
>public bool IsOK { get {return isOK;} set {isOK = value;}}

You probably picked an example that shows the approach in its worst light - but I know what you mean. That said it is the method I use (where it's up to me)
>
>Oh, and the other alternative I see people using is even worse, IMHO ... _IsOK and IsOK. yuk!

In the same way that 'm_' derives from VFP'ers I think that is a carry-over from C++'ers :-}
I can be comfortable with that if ness....

>
>~~Bonnie