Greetings All,
Pamela's message should be answering the questions that I've seen about the parent-child bizobj issue. You are building a hierarchy of related bizobj that will communicate with one another.
In simple parent-child-grandchild relationships the bizobj can use bizobj methods such as:
this.oparent.FetchParentPK() and
this.oparent.GetFieldVal( 'cShoeSize')
as a means of communicatign and receiving an answer.
When the bizobj is not "in the line of sight," two bizobj can still "talk" by creating a temporary connection. The form has a collection that references all the bizobj on the form. Here's where the calling bizobj need to know the name of the called bizobj:
loTemp= thisform.GetParentBizobj( 'bo_sibling')
If loTemp is NULL, there is no bizobj registered by that name. Every bizobj should have bo.cRegisterLabel filled in with a meaningful name so that you can find it using the above method. The builder will help you to focus on setting the important properties.
Obviously GetParentBizobj() is a misnomer. We're not look for a "parent" but we do want to get a reference to another bizobj on the form.
Now you may ask for data or method calls in that other bizobj using the temporary connection. I say temporary because at the end of your method, kill the connection. You run a risk of "danging object reference" otherwise. If you don't know that that means now... you will. 8o)
loTemp= .NULL. will do the trick.
* Two other related answers *
Yes, it is common to have ten or so bizobj on a form. We put all the bizobj on the form so we know they are not part of the ui. The ui is created separatly and added at run time.
Yes, you can create an "empty" bizobj as the form's primary bizobj.
I have one form with a treeview where the primary bizobj is just used to handle the lookup tables and the proxy view for the treeview. Otherwise it does no saves or edits. But what it does do is provides a nice place to send a message that cascades down to the child bizobjs.
You could use some kind of "listener/observer/redirector" kind of thing to do the same thing. In fact we use both. When we need to pass a message outside of the "normal" bizobj communciation, we use a call to the listener. Otherwise, it is easier to just let the bizobj do their normal communication thing.
I hope this makes sense. Sorry if it doesn't. The best advice is to keep working with these things. Consider building a prototype that you will throw away after you see how they are all working. Take what you learned in the simple prototype and build the deliverable. Sure it's a little more work in the beginning... but soon you will know these interactions before you even start. I encourage you to make a copy of the builder libs and then start learning to customize them.
Enjoy.
James Sayer
©2001 James Sayer |
