Really, we didn't even do that in VFP (bad word, I know ).  We used table buffering and didn't commit the changes until down stream.  Granted, it was nowhere as clean as using the BOs and disconnected data, but the concept was really the same.

Trent,

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?

Edhy Rijo

Just call the CheckRules method, not the CheckRulesOnRow.  For example:

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.

Hi Trent,

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)?

Edhy Rijo

Oh, I suppose we could add a cancel parm.  It was created so that there could be a centralized localization for pre-child form initialization code.  Technically the action is already in progress (Delete would actually never hit this event).  So either an Add or Edit will already be in progress.  Adding a cancel shouldn't be too big of a deal, so I will add this to the list.

I think the ListViewBeforeChildExecuteEventArgs event would be a good place to add extra params to send to the Child Form.

------------------------------------------------------------------------
I would like to change the world, but they don´t give me the source code.
MS Windows 7 Ultimate 64-Bit
Intel(R) Core(TM)2 Quad CPU Q9300 2.50 GHz
6.00 GB of RAM, NVIDIA GeForce 9800 GT

MacBook Pro i5 OSX Lion

Hi Trent,

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?

Edhy Rijo

Done, it will be in the next update.  We will post a 1.6.7 beta build in the next week or two, but this will be included.  Here is the update:

Excellent!  this much more than what I asked.

Thanks

Edhy Rijo