Hi Anthony,

I believe that goApp is the only case in which something like this happens.

For the most part, the framework follows the "Chain of Responsibility" pattern.

It probably has to do with the fact that goApp has access to a number of other objects that are important for the app (i.e. security) and instead of following the chain up multiple paths for multiple requirements, goApp acts as a facilitator for these.

If I didn't know Kevin's background in Object Oriented Design and Implementation, I'd consider the possibility that this was an omission, but I have a feeling that this is by design and there must be very good reasons for it.

Have fun!

Alex


>Dan,
>First of all ‘full discloser’ these comments are being made by a person who’s experience with MM is measured in hours, and while he has been working with VFP and OOP for many, many years most likely know less then he think he does <s>
>
>OK this is all IN MY OPINION, but based on years of hard study and experience.
>
>If a program starts at ‘A’ and then calls ‘B’ and then calls…. ‘Z’ ‘A’ is the highest module ( class program etc. ) and ‘Z’ is the lowest. Lower level modules should not call, ask for information etc. of higher modules. GoApp (A) is a very high module therefore the bizobjs ( let us call them B ) should not ask for things like goapp.projectnumber.
>
>Ok then how does B get the information needed, 2 suggestions
>1) Higher level modules GIVE the information to the lower level object.
> Ex:
>oBiz = CreateObject(…..
>oBiz.Set_projectnumber( This. Projectnumber )
>
>2) Both the high and low level object share a common lower level settings object.
>
>This way the ‘B’ bizobject is not ‘tied’ to the existence of goApp. Good OOP should allow for reuse, limit the ties between lower and higher objects, the calls / information flow should only be one way.
>
>In reality MM appears to be breaking my recommendation therefore maybe one should not ‘fight’ the framework.
>
>Anthony