I have three business objects on a maintenance form, Parent, Child, Grandchild.  The Child and Grandchild are both filled for the Parent.  The Grandchild contains all rows that belong to all Child rows for the current Parent.  The Child.ChildAutoFilterOption = MatchCurrentRow.

The Parent is tied to the MaintenanceToolstrip.  The Child is tied to a second, custom, toolstrip.
When Parent changes the Child and Grandchild are filled appropriately.  Navigation and editing work.

When adding a Child I want to also add a Grandchild.  In the custom toolstrip cmdAdd.Click() function I call Child.AddNew().  The Child.AfterAddNew() event calls GrandChild.Add().  When I trace into the GrandChild.SetDefaultValues() I see that the field values show the previous GrandChild row data instead of the new row data (the GrandChild pk is not -1).  It looks like I'm overwriting the previous GrandChild row's data with default values. 

There is a GrandChild_Navigated event on the form where I messagebox the Child and GrindChild pks.  The messagebox does not popup after the GrandChild.AddNew() or GrandChild.SetDefaultValues().  The messagebox pops once with Child.pk = -1 and GrandChild.pk = 88 (prev GrandChild.pk value) and immediately pops again with Child.pk=-1 and GrandChild.pk = -1. 

... a day later ...

Never mind.  If I call GrandChild.Add() in the cmdAdd.Click() after calling Child.Add() it works.  It looks like the Child_AfterAddNew() event occurs before the Child filter and GrandChild navigation occurs so GrandChild defaults are assigned to the wrong row.  So the lesson is don't call AddNew() on a child bo from the parent's AfterAddNew event.  I'm evaluating SF so couldn't trace into its source otherwise I would've figured this out sooner.

You are correct in what you discovered, but one thing that I might caution you on here is using the AutoChildFilter option.  This is a great feature, but I thought I would give you a warning before you start "wondering where your records are going" or "something is moving the CurrentRowIndex."

There is a time and place to use the ChildAutoFilter option but it is generally a better development practice to NOT use this on a maintenance form and only bring back the records that you intend to work with.  When you are using the auto filtering, generally you assume that you are bringing back more records back from the server that you are working with...though this is not the issue I was referring to, it can cause performance issues on larger record sets when retrieving the records from the server.

The issue that I was referring to is that when you add a new child or grandchild record that is filtered, the filter is dynamic, so it is immediately applied and you can be, in many cases, immediately modifying the wrong record since the filter may have moved the records around.  The same thing applies to a sort.  If you are going to use this approach then be sure to turn off the auto-filter when adding a new record and then set it back once the new record is added so that the foreign key can be set (which is what the filter would be setting in most cases).  Hope that makes sense