You're correct up until the part about loading the records related to the parent... it doesn't load any records, you have to do that yourself.  What the ChildFormDialog does is allows you to translate business objects between the child form and the parent form so that when the child form launches, it has the exact same business object references as the parent form.  So, you add a record on the child bo, and it shows up in the child business object on the parent form.  So, you can close the child form without having to save the data, because it's in the child business object on the parent form.

Ok, thanks ben.

Now, about the ChildFormDialog... the way that works is you create two separate maintenance forms, one for the parent, one for the child. Both independant of each other and fully functional. Then using this ChildFormDialog you choose which form  you want to use as the child and it will only load those records related to the parent. Right?

But I cant use the toolstrip that comes with the Maintenance form for the child bo, right?

Not generally... the maintenance form toolstrip calls the methods on the form, which uses the IncludeInForm*** properties to determine which business object(s) to perform the action on.  So, you cannot have multiple MaintenanceFormToolstrips, or they will both do the same thing.

Correct.

Your best bet is to handle the Navigating event of the parent business object and check the IsDirty property on each of the child business objects... if any of them is true, then you should set e.Cancel = True to cancel the navigation away from the current record.

But I cant use the toolstrip that comes with the Maintenance form for the child bo, right?

I'll need separate buttons for add, edit, delete, save, undo, and navigation for the grid/child BO, right?

If i attempt to navigate away from the parent record, how can i detect if there were changes made in any of the child records and then prompt the user?

No, you can still call Add() on the business object to add a new record... it just keeps the grid from trying to add new rows on its own. 

As for state handling... you can handle the EditingStateChanged event of the child business object and enable/disable the appropriate buttons.

I checked the ParentBusinessObject of the form and it was set to the parent. I then set the AllowUserToAddRows to False and it worked. It populated the Grid based on the parent that I navigated to.

Here is my next round of questions...

Does setting AllowUserToAddRows to false prohibit me from adding new rows programmatically?

More importantly, If the form and parent object are a Maintenance form and the child is a grid... how is the add,edit, delete, navigation in the child grid handled? Yknow how do I know or trap if changes have been made and prompt the user to save? or disable navigating to a different parent or child record until the changes have either been committed or canceled?

Thanks

The navigation buttons go off of the object that is the specified by the IncludeInFormNavigate property on the form.  My guess is that the child bo is the first one that you dropped on the form, and it's the primary.  So, when the form loads, the grid automatically adds a record (notice the -1 in the primary key blank) because that's what grids do, and when it adds the record, since the child bo is the primary business object (since it was the first one dropped on the form), it disables the navigation buttons because the business object is currently "adding" and the AllowMultipleModifiedRows of the business object is false.  So, you'll want to do a few things... set your parent business object to be the PrimaryBusinessObject of the form, disable the automatic adding of new rows in the grid (I think it's AllowNewRow or AllowAdd) and add an Add button so that you can manually add new records to the grid rather than letting it automatically create new rows at will.

Ok, I've done all that. However, when I connect the DataGridView to the BusinessBindingSource and then run the it disables the navigation buttons. Pictured below:

Is there something i'm missing?

Ah, the reason that I never created a fill method was because the BusinessLayer class already has a FillByParent() and a FillByParentPrimaryKey() that can be used to pull child records of a parent business object.  You can also write your own fill method, and then filter the records through the ChildAutoFilterOption on the parent business object.

Ok, I'll try that.

The other question I had about Tutorial 14 was... when you create the orders BO you never mentioned in the tutorial that you needed a fill method created.  Is that right?

I understand the parent has a fill method and the link between the parent and the child is created but how does the child BO get populated with the related records?