John:

Thanks - I think I'm finally getting this. I'm going to play around with creating some objects and see if what's in my head actually works. Your help has been real valuable....

Rob

>Hi again Rob ---
>
>>Thanks for the input. I guess I am still struggling with some of the ideas of object responsibility. The use of a messaging object is something I am familiar with, but I still can't resolve how best to incorporate it.
>>
>>Let's say that I decide that whenever the user wants to delete a record, I want to display a message box to confirm the delete before continuing. In the busobject's Delete() method, I tell the business object's messaging object to display the confirmation prompt. I have done this within a complete VFP application without issue.
>>
>
>OK, but now you're running into a violation of UI in the middle-tier. This "rule" is done for a reason, in that COM DLL's can't have UI so don't get used to it :-) I think you more need code like (pseudocode):
>
>IF MESSAGEBOX("Delete")==6 && Whatever...no lang. ref. with me.
> lSuccess=oDataServices.Delete()
> IF NOT lSuccess
> 1. Query message broker
> 2. Instance a message form that shows error message(s) from msg broker
> ENDIF
>ENDIF
>
>>What I get confused on is when you start looking to build the business object as a middle tier OLE server. As I understand it, these middle tier objects can and should reside on other machines. Using the same idea as above, would the message be displayed at the user's computer or the one where the OLE server runs ? And does this violate the idea of not putting any UI code in an OLE server ?
>>
>
>Doesn't matter where the object resides if it's called/instanced from a given client it responds to that client. And the UI issue I addressed above.
>
>>I have seen in some frameworks the use of a global messaging object across an entire application, but if the busobject is created by any other client (VB, etc), then its possible that their is no global message object, since the application object is not created ???
>>
>
>Not at all. If a business object is a true independent object (EXE, DLL) then communicating/using that object is simply a matter of understanding the interface (properties, events, methods) of that object and using it accordingly.
>
>>Sorry this is so long, I guess I am just feeling especially thick today !
>
>No problem, Rob!