Chris,

OK, now I think I understand... or at least I think I understand why I didn't understand before... understand?

Reason being that we would have separate methods in Enrollment, GetGPA() and GetTotalCharges() and most certainly have used GetBizObject() to obtain a reference to MyCourses and MyCharges.

IMHO, if you're using Enrollment as the "top level" object and walking down to MyCourses or MyCharges (or some other "child" object property), then it's legit to expect a public interface on Enrollment for obtaining these values, even if it it essentially turns around and delegates the call to another object (especially if, "You should be able to ask an Enrollment what the GPA is")

Another consideration is future changes to your app (unimaginable as it may seem <g>). What if you decide at a later time to change the way your app obtains GPA/Total Charges? You'd have to hunt down everywhere you use the code below to make the change. In the other scenario, you only have to change Enrollment.GetGPA() or Enrollment.GetTotalCharges() -- hiding the implementation, which is certainly a more desirable design pattern.

>txtGPA.Value = Enrollment.MyCourses.GetGPA()
>txtProgramcost.Value = Enrollment.MyCharges.GetTotalCharges()

>When both Enrollment and MyCourses are on the form, I can set Enrollment.MyCourses = Thisform.Mycourses and be done. This also works when I happen to want a GPA and don't have a MyCourses around to ask -- which is what led me to start this thread.

Right. Here is where GetBizObject() works perfectly. If MyCourses is on the form, it'll find the reference when it checks the form's RefBizObj. If it's not on a form, but still registered as a child to Enrollment, it'll be found in Enrollment's RefBizObj. Otherwise, it'll be created from scratch and the lCreatedNewInstance property is added.

To further simplify matters we've custom coded an object reference property that would be added to Enrollment at run time called "oMyCourses" ("o" + BizObj name)

We've even added code to our kBizObj subclass' Cleanup() that checks all object reference properties, and either "nulls" or destroys the "child" depending on lCreatedNewInstance property existence and value.

>You should be able to ask an Enrollment what the GPA is, but it doesn't know. While the double reference technically breaks strict OOP standards, it makes more sense than adding a function whose sole job is to call the same function on another object.

>My understanding of GetBizObject() means extra code to handle the reference, and isn't as obvious about what is happening.

Yep, this is one of those times where the obviousness of the code and its extreme flexibility may be at odds. We've found that the "set it and forget it" -- with apologies to Ronco -- aspect of GetBizObject() is well worth it.

---J