You can still call it from many different places.  There is a BO that you have on your child form that is bound to your controls.  When you use the ChildFormDialog, it "translates" the BO on your child form to the reference on the parent form.  So the form itself is encapsulated and the ChildFormDialog wires everything up in the Onload of the child form.

So you can still call this same form from many different places because when you call it, you still want to populate the child with the data from whatever parent form you are calling it from.

Hi Thomas,



As Trent says

You can still call it from many different places.

.  As all SF controls, they have a specific purpose, but they are also design to be used in many scenarios, same with the Business Objects, ChildFormDialogs are awesome and flexible, you don't have to use it just to modify a single record, you can do whatever you want, ex: I have cases where I need to modify a child record from different parents in different forms and different child BO, so I do the following:

1. Create a form form with a Themed Panel
2. Drop an instance of each child BO, ex BO1, BO2, BO3
3. Add a Panel Page per each child BO I want to modify and add my controls as usual.
4. In the constructor create a parameter based on a public enumeration that will control which page to activate.
   
5. Override the Onload as suggested by Trent and then set the PanelManager's ActivePage based on the enumeration value, also set the form's PrimaryBusinessObject to the BO you want to work with.
   
6. In the Parent forms, add a ChildFormDialog, select your form and most important, create a translation for the child BO you will be using.  Add a parameter based on the public enumeration in step 4 and you are done!

Again, these are just steps from my mind, so they may not be all needed, but bottom line is to show you that with SF you can think out of the box and be very creative.  I do sort of the same thing with the ListView automations to handle the Add process and instead of showing a child form, I do other stuff.

Edhy Rijo

Hi Edhy,

thanks for your explanations. I dio something similar with some forms like my customer- or my article-editing-forms which can be called from different places and this is working fine. All these forms have in common that the tables used on the childform are alo used on the parent form and the childformdialog does the translation to the childform.

But in this special case which started the thread I don't use the lookup-data (supplier-codes) on the parent-forms which call the lookup-form, so I don't understand why I should there use a childformdialog when it is (now, following Trents advice) working?

Best regards

Thomas

Hi Thomas,


You don't have to use a ChildFormDialog in all situations.  I was simply explaining how I use it and I prefer to stick with the framework tools as much as I can for several reasons, one of them to keep the source code as standard as possible.  I have cases where I used the ChildFormDialog with no BO to do some process and simply return OK or Cancel, so that is the beauty of the ChildFormDialog that it will not lock you to use it for one purpose only.

Edhy Rijo

Hi Edhy,

<< have cases where I used the ChildFormDialog with no BO to do some process and simply return OK or Cancel, so that is the beauty of the ChildFormDialog that it will not lock you to use it for one purpose only. >>

Thanks for that nice idea.

Best regards

Thomas