Juan Carlos Pazos
|
|
Group: Forum Members
Posts: 144,
Visits: 227
|
Hi I 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
Everything is possible, just keep trying...
|
|
|
Greg McGuffey
|
|
Group: Forum Members
Posts: 2K,
Visits: 6.6K
|
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.
|
|
|
Randy Jean
|
|
Group: StrataFrame Users
Posts: 105,
Visits: 641
|
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
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
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.
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
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?
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
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.
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
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?
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 7K
|
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).
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 7K
|
|
|
|
Paul Chase
|
|
Group: Forum Members
Posts: 414,
Visits: 2.8K
|
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 7K
|
Sure  Sorry for the trouble!
|
|
|