Bill;
At the center of any class based method there will be procedural code. Classed methods call procedural methods. The advantage of using classes could depend on what we need to accomplish and our individual styles. My initial aversion to classes were the big words, like "polymorphism" and "inheritance" (LWTFC's). Even to this day, when I read, hear or use the word "instanciate", my neck twinges (Ouch!).

When we OLE/COM with Word, Excel, Outlook, ActiveX; etc, we have to work with objects (VBA/OLE Script) to transact with the server(s), but we grind it up and pass back info built procedurally. In these cases a general knowledge of OOP is helpful.

Classes can be used contain and reference multi-tiered data. Kind of like building a macro command string, but more elegant. Classed refrences can augment a procedural solution. We would be hard pressed to suggest that a detailed expert understanding of OOP could ever serve as a substitute for a good procedural discipline.

You've heard of subclassing. You pull Text Boxes off the VFP control bar, lay them on a form, open method editors and write an interactivechange method that enables a command button. With subclassing, we only need to write that method once. The subclassed clones will all have the codegenes to switch the button's enable without rewriting the code in each text box!

So do what you do best. If you feel a need to use classes to augment your procedural style, then go for it!!

I'm off this soap box now!/Regards


>Jim,
>All of your arguments can easily be applied to a PRG also (except #1 possibly). In fact as a PRG they are simpler, particularly # 2.
>
>
>>Bill,
>>
>>Here are some arguments in favor of using an object for this.
>>
>>1. Can easily subclass the class to vary the functionality without needing another function and syntax for its use
>
>This is 1 of the things I consider when deciding on a VCX or PRG. But in the case of something so simple as a MessageBox, #2 becomes a significant factor.
>
>
>>
>>2. The object can be instantiated by the application object and held as a system level utility object so calling it is simply;
>> oApp.oMsgBox.Display(...)
>
>How is this simpler than:
>MB(...)
>
>
>>
>>3. Since oApp holds the reference to the message box object oApp can change the class being used at its own discretion thus providing a single location for changing the appearance of the message box for the entire application.
>
>just changing the code in MB.PRG changes the appearance of the messagebox for the entire application.
>
>
>>
>>4. Since the oApp object holds the object reference there is only one place to deal with its release, which sort of negates the argument that there is some problem with cleaning up after the object.
>
>with MB.PRG there is NO cleanup involved at all
>
>
>>
>>5. The interface to the message box could be designed into the oApp object (making the calling syntax something like oApp.DisplayMsg(...) )so one of the arguments could determine which type of message box to use (tell oApp which subclass to use) and the interface to the msg box featres would remain consistent across all types of msg boxes.
>
>Just adding another lParameter to MB.PRG would allow the same capabilities.
>
>
>>
>>There are more but I think that is enough to indicate that using a class and object provides much more flexibility for the future.