Glad I found this post, I have been trying to figure out why a weekly import routine quit working correctly and thought I was crazy cause the BO was starting on the second record. Thanks for finding this one it saved me some time trying to figure out why the record pointer was on the second record.

In BusinessLayer.Events.VB

I wondered what was happening. I've also noticed this, but figured I was doing something wrong. I made a demo using SF sample data and indeed, it is reproducible.

In the CRM sample app, add a FillAll method to the customer BO (without a movefirst after the filldatatable):







Then, in the customer maintenance form load, call the new fillall method:







In my case, when I run the form, I can click the "back" button on the binding navigator and there is indeed a record that it skips back to - but it should actually not be able to skip back if it is indeed on the first record. If this doesn't happen to you, then I'm not sure what could be different. It does this on every business object we have and we're not setting any sorts for filters of any kind. Also running the latest SF beta of 1.6.6 I believe.



Thanks,

Randy

Trent was looking at the code behind this the other day, and the CurrentIndex is indeed getting set right after the filldatatable, so I'm not sure how that could be an issue. 

However, if it is reproducable, could you post that sample up as an attatchment so we can take a look at it. Ben didn't mention anything to me about it, so he may have already addressed this (he's on vacation at the moment, so I can't just go ask him ). Regardless, a sample that uses the StrataFrame Sample info and fails on your end will tell us for sure.

Actually, a movefirst is what we want instead of navigate, I believe. Navigate tries to update bound controls so don't think that's needed if doing this inside the fill itself.

This is a re-producible issue that I showed Ben on the last day of training in Amarillo using sample app business objects and he confirmed it definitely was not a filter/sort issue with what I showed him, but immediately after the filldatatable, the currentrowindex was set to the 2nd record (or actually a 1 vs. a 0). Sure, putting a navigate in the fill method should rectify the issue, but still curious as to what's actually causing this to happen. I had been meaning to follow-up with Ben but been real busy with some other projects and just getting back to some Strataframe work myself. This has bitten us a few times but we've managed to just work around it for now.

Hi Juan Carlos,

Try putting the Navigate() command in the BO.FillTodos(), that way you keep the code related to the BO in the BO in case you need to call BO.FillTodos() from another place and want to have the records properly sorted.

Edhy Rijo

Hi



Just found the solution:



Private Sub FamiliasBO1_ParentFormLoading() Handles FamiliasBO1.ParentFormLoading

'-- Load BO

Me.FamiliasBO1.FillTodos()



'-- Go to first record

FamiliasBO1.Navigate(MicroFour.StrataFrame.Business.BusinessNavigationDirection.First)

End Sub



As the FillTodos is already sorted, I only need to go to the first record. Without that the BO loads ordered but shows the first record in the primary index. Navigate to the first record puts the form just as I need.



Thanks all for your help.

Everything is possible, just keep trying...

I promise that this is your problem.  If you put a break point you will see that the data behind the CurrentRowIndex is changed....the ONLY way that this will happen is through a filter or a sort or manually changing the data table and/or view.  You are welcome to post a sample, but I have seen this too many times in the past and I am confident that is your issue.