I've just spent a considerable amount of time debugging a form that wasn't working. I finally tracked it down to the following code:

This just loops continuously. Once I found it, I very easily fixed it as follows:

This is much better anyway, and I've checked our codebase to ensure there were no other instances of the former method.

The reason I'm raising this is that this form had been working (although I'm unsure how recently), the code had been as I found it at least since the start of November 2007 (I haven't checked back any further), and the code would have been executed every time the form was used. The only change that I can relate it to is an update to VS2008 and SF 1.6.5. I'm wondering if this is a deliberate change in behaviour of Save(), an accidental change in behaviour, or behaviour that was always expected and my code used to work by some strage quirk of fate.

I thought you might be interested.

Peter

This method implements the IEnumerable interface and will save of the index positions and reset them once complete without you having to worry about it.  This is practically the only way we enumerate a BO any more. 

I've been implenting GetEnumerable, in place of MoveFirst/MoveNext throughout our solution, and it works very neatly. However, I've come across a method where the bo is filtered before being processed. I've looked up the documention and MoveFirst/MoveNext processes the CurrentView, but I wasn't able to determine if GetEnumerable processes the CurrentView or the raw datatable. Can you enlighten me please?

Peter

We have a ParentBO and ChildBO both on the same form in separate grids with the Parent/Child relationship set up so that the Grid displaying the ChildBO only shows those rows related to the Row selected in the Grid Showing the ParentBO (all good so far). Now what we need to do is to process through rows displayed on the ChildBO Grid.

We thought that we could process through the ChildBO using the techniques we've been discussing, because we thought the Parent/Child relationship filtered the ChildBO datatable to give a CurrentView that just has the rows displayed. However we noticed the processing was not behaving as expected and then discovered that the CurrentDataTable and the CurrentView were the same (no filtering). What should we do in this instance?

Peter

All BO methods, including the GetEnumerable, use the CurrentView which respects the fitlers, sorts, etc.  Another nice thing about the GetEnumerable is that it saves of the CurrentRowIndex and resets it for you as well, saving you a little work here.

I guess I don't totally understand what you are trying to do here in the area of the filter.  So let me just explain how the filter actually works.  When you set the Filter property on the BO, it is actually setting the CurrentDataTable.DefaultView, and the CurrentView is just exposes the CurrentDataTable.DefaultView.  So the only way that they would be the same is if 1.) the filter applied includes all records 2.) no filter is applied.

Let me know if this is not going down the right direction.

The issue is with a standard pair of parent/child BO's on a form where the datasource for the child returns all rows but the child grid display is filtered using the standard ChildAutoFilterOption>MatchCurrentRow.

What we are looking for is the recommended way of iterating through the child BO so that the only data processed matches the current on-screen display in the child grid.

Cheers, Peter

Sorry, my mistake. I see now that the CurrentView is filtered by the ParentBO.

Cheers, Peter

Thanks for the info, it is all clear now.

Peter