>>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(...)

Actually I prefer the use of a strategy pattern here where the call is oApp.MsgBox(...) and oApp decides what to do with the call.


>>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.
>

Using a strategy pattern allows each call to decide what type of msghbox it wants. With Functions you would need a separata function for each type of msgbox and the calls would vary for each type. With oApp.MsgBox(...) one argument could cause oApp to use a completely different class for the msgBox object allowing a virtually unlimited number of variations.

>>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
>

And so it could be using an object as well if at the end it destroyed itself.

>>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.

Not really, using the strategy pattern oApp copuld keep the msgbox in memory so subsequent calls were faster than the original call. Even the msgbox form itself could be kept in memory for future use (if you were using your own form for the msgbox) and since oApp will be destroyed when the app ends it can clean up any objects it created during the apps run on its own destruction.

Besides, once introducing the idea of a stratgey pattern in the oApp object there are many other areas of the app that can make use of the same concept. Things like toolbars (shared between forms), other utility forms like selection criteria for locates or select commands, etc.. All opf this through one syntax of oApp.Utility(...) or whatever you descide the method of oApp will be for that functionality.

I don't argue that a UDF doesn't have its palce, only that each time I have used a UDF it proved to be shortsighted on my part later on.