By Juan Carlos Pazos - 7/29/2008
HiI have a curious situation. I have a table for families, the BO has this method: Public Sub FillAllRecords()Me.FillDataTable("SELECT * FROM Familias ORDER BY Apellidos")End SubI add three records, one begin with H, second with D and las one with A. Every time I load the maintenance form, goes to the second record in this case the one beginning with D, the order is correct, the first record is the one with A but I can not understand why goes to the second one. Regards
|
By Trent L. Taylor - 7/30/2008
You can actually find your answer to this throughout the forum....it becomes a common post. You have a sort or filter set on your BO which changes the order of the internal data table, but the CurrentRowIndex is left the same. So when you add a new record or modify a column that is part of the sort or filter, you will either need to clear the sort or filter or take this into account. This is a very common thing that we see out here on the forum, but I am 99.99% confident that you have a filter or sort applied to he BO or something along those lines that is changing the order of the records in the BO.
|
By Juan Carlos Pazos - 7/30/2008
Hi TrentSorry but I dont' have any sort or filter in the form. As I show before the SELECT statement has a ORDER BY and yes the order is respected when the form loads, the only thing is that the record that shows when the form is opened is the second one and the first one. I review the forums yes but at least the ones I tale a look was on how to use a SORT or how to after save show the records sorted again. I will review again, maybe as you said is the CurrentIndex... that goes to the second record and I don't know why? regards
|
By Trent L. Taylor - 7/30/2008
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.
|
By Juan Carlos Pazos - 8/4/2008
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.
|
By Edhy Rijo - 8/5/2008
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.
|
By Randy Jean - 8/21/2008
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.
|
By Randy Jean - 8/21/2008
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.
|
By Dustin Taylor - 8/22/2008
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.
|
By Randy Jean - 8/22/2008
In the CRM sample app, add a FillAll method to the customer BO (without a movefirst after the filldatatable):
Public Sub FillAll()
Dim loCommand As New SqlCommand()
'-- Create the command
loCommand.CommandText = "SELECT * FROM Customers Order By Cust_Company"
'-- Execute the command
Me.FillDataTable(loCommand)
End Sub
Then, in the customer maintenance form load, call the new fillall method:
Private Sub CustomerMaintenance_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Customers.FillAll()
End Sub
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
|
By Greg McGuffey - 8/22/2008
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.
|
By Randy Jean - 8/22/2008
In BusinessLayer.Events.VB
'''
''' Raises the MicroFour.StrataFrame.Business.BusinessLayer.CurrentDataTableRefilled event.
'''
'''
Protected Overridable Sub OnCurrentDataTableRefilled()
RaiseEvent CurrentDataTableRefilled()
'-- Navigate the record
Me._CurrentRowIndex -= 1
' This is the line causing it - don't know why this is needed...
Me.Navigate(BusinessNavigationDirection.Next, 0, Nothing, False, True)
End Sub
|
By Paul Chase - 8/25/2008
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.
|
By Paul Chase - 8/26/2008
Ok now that I know what is happening I really urgently have to fix it as it is holding up a weekly data import, I really don't want to have to go through all the fill methods and make sure the record is in the correct position. Any ideas on what is causiing this and what needs to be changed to fix it?
|
By Paul Chase - 8/26/2008
Any ideas?
|
By Paul Chase - 8/26/2008
Is there a difference between the source posted in the user accounts section and the latest build that is posted here on the forums? I needed to get this working ASAP so i just obama rigged my import code to check to make sure it was on the first record after filling , after that i decided to see why it was doing that and to make sure I had the latest source I downloaded it and rebuilt it on my system and then issue was gone, I did not change anything just downloaded and rebuilt it in debug so i could step though. I could be going crazy it has been a long day but I am thinking that is what happened. I'm going to leave well enough alone and get while the getting is good but figured id post this just in case im not crazy.
|
By Paul Chase - 8/27/2008
Well as I thought that was to good to be true I guess I must have mismatched version's or something because the Strataframe addin would not load this morning, I reinstalled back to the latest beta version and that fixed the problem with the add-in but I still have the issue with the record pointer being in the wrong place. Just curious if the SF guys are looking into this?
|
By Trent L. Taylor - 8/27/2008
Fixed...creating a new build as we speak and will post it within the next 30 minutes or so. This problem was actually introduced on April 28, 2008 (during the 1.6.6 beta) in response to fixing another issue. If you look at the SF source code, the _CurrentRowIndex is not a private but a property that was changed from a private to a property when the Shared DataTable was introduced to the framework. Per some other threads and forum posts, there were certain conditions where the _CurrentRowIndex would be set to an illegal value on a Save or Undo which would produce an error (when records actually existed within the BO). This was actually a correct change, but the framework had original code which attempted to set the index back 1 and then call the Navigate(Next)...well, if the _CurrentRowIndex was set to an illegal value, the index would not move...thus when the next was called, the record would move forward since the _CurrentRowIndex didn't actually change. This has been changed by logically raising the Navigated event and refreshing the bound controls versus forcing a navigate in all areas that had this logic...in short, it was an easy and quick fix and I will let you know when we have the new update posted (should be just a few minutes).
|
By Trent L. Taylor - 8/27/2008
Here is the fix: http://forum.strataframe.net/FindPost18786.aspx
|
By Paul Chase - 8/27/2008
Thank's a bunch Trent
|
By Trent L. Taylor - 8/27/2008
Sure Sorry for the trouble!
|
By Alex Luyando - 3/17/2009
Trent L. Taylor (07/30/2008) You can actually find your answer to this throughout the forum....
I never was able to find lots of Easter Eggs buried in the sand either... I give up! Where can I find the answer?
I understand the RowIndex is causing my toolstrip's navigate buttons to cause the highlighted row in my listview and the other bound controls to "jump" in a sequence that is not expected based on the current sort order of the BO's datatable (i.e., the listview's rows are not sequentially navigated), but have not found how to handle this... only quite a few "yeah.. it's posted out here elsewhere" replies
It's probably right in front of me, but...
TIA
|
By Trent L. Taylor - 3/18/2009
Alex, I guess I don't understand your problem. Your problem could be happening for a lot of reasons, and I don't think I have enough information to give you an answer. Are you using the fully automated population of the ListView including the management of the Add, Edit, Delete buttons? Or are the buttons you are referring to a MaintenanceFormToolstrip? What is changing...when you select a ListView item the toolstrip is updated or when you navigate the ListView selected index is changing?
|