First, thanks for all the enhancements done to the ListView, very impressive

I setup a form to test the ListView and found the following issues:

• Moving the record pointer in the ToolStrip button does not update/refresh the ListView.
• Creating a new record or modifying an existing one does not Refresh the ListView with the updated data.

I tested the functionality of the Add/Delete/Edit Objects and they all worked as expected. 

One question, when using the ListView with a child BO, I may need to have buttons for Save/Undo if not using a childform object, would you consider adding a SaveObject/UndoObject as well for this case?

Please take a loot at the video in this link:  http://www.progytech.com/videos/Beta_ListView\Beta_ListView.html

This is the whole point of a parent relationship.  You SHOULD be able to create a child record on a parent that doesn't yet have a PK yet.  SF will automatically persist the parent's PK to the child once the parent gets a PK.  So you should be saving these records at the same time.  It isn't fair to require the end-user to save a parent record before a child gets created.  All of this should be able to be done at the same time.

In one maintenance form that I recently finished, I have 11 child and grandchild records that could be created on a new record without ever first requiring a parent record to first be saved.  So that is the first thing I would rework versus forcing the save of the parent.

• So basically all child BO should be Saved when clicking the Save button in the Parent Form? 
• I guess that if I select Undo from the toolbar that all child data will be undoed?

Guess I am still thinking as a VFP developer

Yes.  All Save and Undo logic should occur from a single point (not the child form ) but the most common place would be the Parent form or container.

Yup...you got it

After your post, I when to check the SF Samples and after reviewing the ChildDialogFormSample.sln I think I now have a better understanding of this concept of drilling down child forms and having control of all the savings from a single point. 

I must admit that it still scares me a bit drilling down several child forms without saving and potentially undo some data that the end user may not wanted to undo, but I guess is just a matter of understanding the design purpose of the ChildFormDialog control.

I'll keep you posted

Refactoring my child forms, i have a situation with my current code in the ChildForm Save button:

As you can see, I am using the Form's Save() to force the Broken Rules check and show the InfoBox.  But intent to refactor it to simply check for broken rules and return a DialogResult.OK as it should be.

In the CustomerNodeEditor form this code is being used for the same reason:

The CheckRulesOnRow(True) is not working in a sense that is not showing the required fields nor showing the InfoBox to inform the user that there is a problem with that record, but it is not entering the IF condition which mean that it is partially working.

How can I deal with this situation since in all my ChildForms I need to check for broken rules defined in the BO class?

All of the error providers will then work, however, the InfoBox will not appear and this is by design.  That logic is placed in the Save() of the BaseForm and creates a collection list...however, you can add this yourself very easily in your BaseBO.  Just handle the BusinessRulesChecked event of the BaseBO, and you will probably want to have a property that determines if the InfoBox will be shown when there are broken rules (this too would be on your BaseBo).  The only other property that you may consider adding or testing for is the parent form (or which ever form you may want the InfoBox to show within).  But you would then call the InfoBox like this:

You can look at the BaseForm in the Business assembly of the source to see what we do in that dialog.

In the latest update 1.6.6 a new event BeforeChildFormExecuted was added to the ListView control.  I noticed that in the ListViewBeforeChildExecuteEventArgs there is no Cancel property to cancel any action handled by the ListView control.

Would it be necessary to add the e.Cancel property, or is there any other way to abort any of the 3 actions allow in the ListView (Add/Edit/Delete)?

I really have the need to be able to cancel out showing the childform dialog from the listview BeforeChildFormExecuted, I have not find a way to do this in a form without having to have all the listview code in the form to manage it. 

Have you consider adding an e.Cancel parameter?

Thanks