Hi Mark,

Don't mind you jumping in at all ... the more, the merrier (and hopefully it means I'll learn more OOP).

You've made a few good points that I'll keep in mind. Plus, using these classes (even if they are just methods) at least gets me in the OOP mood. :-)

Thanks!
Bonnie

>Bonnie,
>Pardon my jumping in here...
>If your classes are nothing more than methods, there isn't much difference. Otherwise, there are many:
>*You can define visual classes: when instantiated, are visual objects.
>*You can create object classes not possible in the class editor, such as Columns. Then you can add this custom class (with your custom methods) into a grid, programmatically.
>*You can have code that has 'object' behavior: In my app, I define an Environment object - it's nothing more than a bunch of properties and methods that save, set, and restore environment settings (set talk, etc...). What's great about CREATing it is that the destroy event (which restores everthing)ALWAYS gets called - even if you get an error, or cancel, or QUIT, etc... - all because it is behaving as a object.
>
>-just my $0.02 US...
>Mark
>
>
>>Another question ... what is the benefit to making these classes instead of just the ordinary old functions/procedures that we're all used to using? After all, I ended up putting them into a procedure library that's accessible from the entire project ... what's the diff? Enquiring minds want to know! < g >