Paul/Jim

Yes - to me - PRIVATE vars are the real no-no - the ones to be avoided like the plague. Not that I disagree with the notion that publics are bad also - but at least there's a clear understanding of what the difference between public and local is. PRIVATE inhabits some dark nether-region in between :-)

For my purposes - as Jim B. pointed out - I would get identical functionality within my app by either using a public and making sure to clear it - or using a provate. I just don't like privates - like them less than publics. In any case - we're all better off to limit it to one little var and have everything else local and well encapsulated.

Ken


>>>>So when is a var required to be public?
>>>
>>>Only when its real scope is over the entire application.
>>
>>Incorrect, it is only when its requried scope extends beyond the routine that creates it. A private in the startup program is global to the entire application.
>
>Technically, yes. But if I declare a variable as PUBLIC, anyone will understand that I mean it to have public scope. If I declare it PRIVATE, some may wonder if it was intended to be private from a higher level or is just a programming issue.
>
>>I propose that using publics is a bad design in itslef.
>
>I know. :) And I agree with you (for my own applications). But this doesn't mean any other design that uses public variables is bad.
>
>Vlad