Current Record?

[JaedenRuiner]

Okay,

BindingSource, BindingNavigator, DataSet (Typed), TableAdapter (Typed). All on the form. Dropped in a "Details" view of the appropriate Table I wish to view. Now for the kicker:

Where's the current Row?

If I remember they used to be called "cursors" or something of the like in old DAO and ADODB back in my Access days, but this is SQL Server and ADO.Net, so I haven't a clue if that's still the same.

See on the Binding Navigator there is that "PositionItem" property which is set to a ToolStripTextBox. Where is that populated...with what property, value, etc. I've examined the DataSet/DataTable/DataView types and I don't see any "CurrentRecord" property, so i'm a little confused on the BindingNavigator control and how it works with the details form.

Thanks

 

[JohnH]

BindingNavigator is only linked to a BindingSource, and interact with the BS properties, methods and events. Ex: BS.MoveNext() > BS.PositionChanged event > get BS.Position.

 

[JaedenRuiner]

Ahh..

I Didn't look at the BindingSource properties/methods. Whoops.

Thanks, that's what I was looking for

 

[cjard]

i normally declare a private property on the form:

Private Property CurrentXXXRow as MyDataSet.XXXRow
  Get
    If myXXXBindingSource.Current Is Nothing Then return Nothing
    Return DirectCast(DirectCast(myXXXBindingSource.Current, DataRowView).Row, MyDataSet.XXXRow)
  End Get
End Property

and then just call it all over wherever needed


ps do not be tempted to access rows in the DataTable. The BS maintains position independently of the datatable.

Do NOT for example, use the BS.Position and use it as an index to access the DataTable.

If your BindSource is sorted or filtered, then Position 0 in the BS does NOT correlate to row 0

 

[alim]

thx

i normally declare a private property on the form:

Private Property CurrentXXXRow as MyDataSet.XXXRow
  Get
    If myXXXBindingSource.Current Is Nothing Then return Nothing
    Return DirectCast(DirectCast(myXXXBindingSource.Current, DataRowView).Row, MyDataSet.XXXRow)
  End Get
End Property

and then just call it all over wherever needed


ps do not be tempted to access rows in the DataTable. The BS maintains position independently of the datatable.

Do NOT for example, use the BS.Position and use it as an index to access the DataTable.

If your BindSource is sorted or filtered, then Position 0 in the BS does NOT correlate to row 0

thanks i also need this too... but i can't find out how could i can do it...

 

[cjard]

thanks i also need this too... but i can't find out how could i can do it...

I can't work out if youre asking a question, if you have a problem, or if youre just thanking me for providing you with some useful code

 

[roblesrt]

i normally declare a private property on the form:

Private Property CurrentXXXRow as MyDataSet.XXXRow
  Get
    If myXXXBindingSource.Current Is Nothing Then return Nothing
    Return DirectCast(DirectCast(myXXXBindingSource.Current, DataRowView).Row, MyDataSet.XXXRow)
  End Get
End Property

and then just call it all over wherever needed


ps do not be tempted to access rows in the DataTable. The BS maintains position independently of the datatable.

Do NOT for example, use the BS.Position and use it as an index to access the DataTable.

If your BindSource is sorted or filtered, then Position 0 in the BS does NOT correlate to row 0

Thanks this is very helpful indeed

 

[acidflash]

Another way to do it is the following

Dim increment as integer
increment = Me.YourBindingSource.position

YourTableDS.Tables("YourTable").Rows(increment).Items("YourItem") = blah
YourTableDA.update(YourTableDS, "YourTable").

Good luck.

 

[cjard]

No, no, no, no, no! Never, ever, ever use the BindingSource.Position as a row index!

There is NO correlation between bindingsource position and row index!

The attached project demonstrates this

 

[acidflash]

cjard, I downloaded the project. When using a listbox it seems to work? I used this in my project and it apparently works fine? In what situations is it wrong to do this ? Thanks for the advice.

acidflash.

 

[JaedenRuiner]

the Binding Source position is not directly related to the Ordinal Index of a DataTable Collection of DataRows.

Thus, if you have say a series of Customers in a datatable, and you load them from the database, lets look at a list of names here:

1. Smith, John
2. Doe, Jane
3. Rogers, Buck
4. Brady, Marcia

Now, from a direct pull from the database they are mostly likely filled by a row id or other such method so most often they are in the same order they were entered, but even that is not perfect so you can never count on db order.

but for the moment lets assume the above is how they are pulled from the database.

BindingSource.DataSource = CustomerTable
BindingSource.Sort = "LastName ASC, FirstName ASC"

1. Brady, Marcia
2. Doe, Jane
3. Rogers, Buck
4. Smith, John

Now you have
BindingSource.Position(1) = Doe, Jane
CustomerTable.Row(1) = Doe, Jane
Wow it works! No. ONly one row stayed the same so in this example it's pretty obvious the changes made as BS.Position(2) <> CustTable.Row(2) and that is why you never consider the BindingSource position to equate to the row.

 

[cjard]

cjard, I downloaded the project. When using a listbox it seems to work? I used this in my project and it apparently works fine? In what situations is it wrong to do this ? Thanks for the advice.

acidflash.

I recommend you look at the grid on the left. Click on the fourth row. Look at the BindingNavigator at the top, showing you the .Position: 4

But look at the data! Is it the number 4/word FOUR? No! Go ahead and edit the word.. youre editing in position 4. What row in the table changes? It's not 4...

 

[acidflash]

While I understand what your saying, i have the current situation in my project. There is a listbox that is bound with a bindingsource to a database, when I click on the an item in the listbox, the .position ALWAYS gives me the right row; Now, as i can see from your posts this is not good practice and I will try to adapt better code if you can suggest some that would be greatly helpful, it will be saved as a code snippet. Thanks in advance.

acidflash

 

[JaedenRuiner]

While I understand what your saying, i have the current situation in my project. There is a listbox that is bound with a bindingsource to a database, when I click on the an item in the listbox, the .position ALWAYS gives me the right row; Now, as i can see from your posts this is not good practice and I will try to adapt better code if you can suggest some that would be greatly helpful, it will be saved as a code snippet. Thanks in advance.

When dealing with binding Sources and their position, instead of using the DataTable.Row(position) method always reference the "Current" property of the bindingsource:

'Given DataSet is A Typed Dataset with a DataTable and DataRows
'MyTypedDataSet, MyTypedDataTable, MyTypedDataTableRow

public Property CurrentListRow() as MyTypedDataTableRow
 Get
  if (BindSource.Current isnot Nothing) andalso (TypeOf BindSource.Current is DataRowView) then
     dim dr as DataRow = DirectCast(BindSource.Current, DataRowView).Row
     if (TypeOf dr is MyTypedDataTableRow)
       return DirectCast(dr, MyTypedDataTableRow)
    end if
  end if
  return nothing
 end get
end property
end sub

now, if you are only using the binding source on your typed dataset, you don't necessarily need all the typeof checks, but that's the basic setup. BindingSource.Current is a DataRowView type when the BindingSource.DataSource is a DataTable or Dataset (with DataMember pointing to Table Name).
The DataRowView.Row property always points to the precise DataRow in the DataTable source where the BindingSource's Position is indicating, regardless of the DataTable Row's Ordinal Index.

 

[cjard]

You could probably leave out some of the type checks in JR's example but the premise is sound and this is definitely what you should do. Read up on the MVC concept, and always be aware of what objects in your program are M, what are V and which are C. Some are dual purpose, but never mix logic intended for an M with that of a V etc - of the 3, M is, or ought to be, the most isolated from the other 2. The other 2 are often represented by a dual purpose entity.

While I appreciate that in your program, with limited cases of use, position and row may be analogous, the problem is that you may one day:
a) find that they are not, and be really stuck
b) recommend to others that they follow this way (and then they will get stuck)

I'm sure you can appreciate that it is always better to develop good habits from the start