I have a form with 2 BO, when I click Edit button and there is no child record, I got the error above.  The child BO has the following properties set to True: IncludeInFormEdit, IncludeInFormSave and IncludeInFormUndo, the rest include... properties are set to False.

I have been searching the help file and this forum but have not find a way to prevent this error.  I was under the impression that the Edit code will check if there is not record in the child BOs and skip the edit state on those BO?

No.  If you have the IncludeInEdit set to True, which there is really no reason to, then it will call the Edit on the BO.  If there are no records then you will get this error.  This is by design.

I never allow the MaintenanceFormToolstrip automatically set the Edit state of a child BO, only the primary.  Obviously you want actions such as Save and Undo to handle all BOs, but in this case, unless you will always expect a child, then there is no reason to do this.  Additionally, if you are using a ChildFormDialog to present the child record for editing, then you would set the Editing state then (immediately prior to showing the child dialog).

There are other options too such as always allowing modifiction by setting the ManageUIReadonlyState property to False and then manage the IsDirtyChanged event.  Just another approach.

But this is be design...the Editing state is by business object, not row.  So it only makes sense that a BO with no records should not be allowed to be set to an Editing state.  If we were to ignore this and just set it anyway, then this would have adverse downstream effects.

Basically this is a form that will handle a One2Many relation (see image below)

At this stage I am trying to set my basis for all forms using the same type of OTM relation.  As you can see, I am handling the Add/Remove service (child BO) with the 2 buttons below.  Initially I though of using another ToolStrip for the child BO but then will need to add code to handle all buttons navigation.  By using the "Include..." properties I noticed that the Edit/Save/Undo of the main ToolStrip will take care of the child BO and everything is working just fine, except for this error I got testing with no data in the child BO.

I have some questions about this situation:

1. From SF design view, does it make sense to handle the child BO this way?
2. Would it be an easy way to prevent the error above by checking the BO.Count = 0 and canceling the Edit for the child BO?

Thanks!

Not really.  We have developers that have gone down this road, but having a single MaintenanceFormToolstrip that tries to do it all...well...you are going to have troubles.  This partially goes back to the post I made the other day about the changes I made to a listview...it will autonavigate when a record is selected.  But that aside, it is really dangerous, SF or not, to rely on that one navigation object to keep all of your BOs in sync. 

I really don't know why you are so concerned with the Editmode anyway.  I see that you are using a grid...as soon as a field changes, the BO will updated...the editing state is primarly (if not exclusively) used for managing the UI field states...nothing more.  If you REALLY want to know whether a field has been added, modified, etc, you will want to look at the RowState of the CurrentRow obejct:

No a problem, I did not have that functionality before in VFP so there is nothing to miss , basically I am just exploring what can/can't do with SF, and though I could have saved some time by letting the MaintenanceFormToolstrip handle some of the child BO behavior.  I will fix this to use the MaintenanceFormToolstrip the proper way and manually handle the child BO Add/Remove/Save.

Well, I am using a ListView here but I don't think that will makes any difference.

Thanks will do so.

You are correct in that it won't make a difference.  As I mentioned, the EditMode really only pertains to the UI editing state.  This is used to create synchrony between the UI controls and the MaintenanceFormToolstrip, etc.  This is good for a primary BO, but downstream (child) BOs that appear on another form will not matter in this case.