Storing ListBox.SelectedIndex 1

[Crystalyzer]

I have a listbox that is populated by a dataset and I am looking for a way to store the selectedindices so that I can compare then to see what has changed. Based on the changes I want to delete a record (from other data not the list)if it is no longer checked and add a record (to other data) if a new item is checked. If an item stays checked I don't wish to do anything. Could anyone point me in the direction of where I can store the initially selected values for comparison?

Thanks and best regards,
-Lloyd

 

[Crystalyzer]

BTW this is a multiselect listbox.

Thanks and best regards,
-Lloyd

 

[chmohan]

Does this help,you might have to use a DataRowView and then store them in an array or so

http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/VB_DOT_NET/Q_21426434.html

 

[Crystalyzer]

Thanks chmohan,

I saw that too when I googled my question, but was trying to avoid siging up on a pay site for the answer.

I guess I'm cheap.

Thanks and best regards,
-Lloyd

 

[chmohan]

you mean you cant access it? I can


Accepted Answer from FernandoSoto
Date: 05/17/2005 07:20AM PDT
Grade: A
Accepted Answer


Hi Erick;

Try this out

Dim SelectItems As DataRowView

For Each SelectItems In ListBox1.SelectedItems
Console.WriteLine("Display Member = {0}", SelectItems.Row.ItemArray(0))
Console.WriteLine("Value Member = {0}", SelectItems.Row.ItemArray(1))
Next

 

[ThatRickGuy]

EE has about the crapiest inteface ever conceived. It's designed to make you think you need to pay to access the info, but if you hop through enough hoops you can usually find the solution with out paying for it.

In any case, when you have a list/combo box data bound, each item is considered a DataRowView instead of a string. So to access the value you need to grab the values as if it were a data row view.

Listbox1.SelectedItems(0).Row.ItemArray("[FieldName]")

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[Crystalyzer]

chmohan,

Thanks for the code. It works like a charm!



Thanks and best regards,
-Lloyd

 

[BobRodes]

<each item is considered a DataRowView instead of a string.
My first foray into the ListBox involved recreating a VB6 application that read values into a recordset and then populated a ListBox, adding a key value to the ItemData property. Needless to say, that was more complicated than the more typical use of the ListBox. In any case, I believe that each item in the Items collection is actually an object reference, even if you're using a simple string value. Perhaps you will correct me if I'm wrong. In any case, I just posted a reply on thread796-1127589 that reflects this.

 

[BobRodes]

I looked it up, and

http://msdn.microsoft.com/library/d.../frlrfSystemWindowsFormsListBoxClassTopic.asp

suggests that the Items property represents a reference to a ListBox.ObjectCollection object, which itself is a collection of object references to any object desired.

HTH

Bob

 

[ThatRickGuy]

True, but if you populate a listbox with the traditional

listbox.add("Some value")

the .items collection will contain strings.

If you populate a listbox with

listbox.datasource = datatable

the .items collection will contain data row views.

Now, you can also create custom classes and bind or populate the list box to an object of your custom type. But the most common problem is when people try to use the listbox.items collection like a collection of strings no matter how it was populated.

Also, I messed up that snippet from my last post. should have been:

CType(Listbox1.SelectedItems(0), DataRowView).Row.ItemArray("[FieldName]")

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[BobRodes]

I thought that what happens is that the .items collection will contain pointers to string objects. Is that not correct?

 

[ThatRickGuy]

The collection I beleive (don't quote me on this) does contain pointers, and not a copy of the value.

But those pointers/values are of type object, so you can put anything you want into them. If you populate the listbox with strings, using listbox.selecteditem will return a string. If you populate it through data binding, listbox.selecteditem will return a datarowview. If you populate it with your own custom object listbox.selecteditem will return a value of your custom object type.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[BobRodes]

Yes, that's my understanding. But isn't a string an object too, in VB.Net? That's what I'm getting at.

As for the pointers or values question, Listbox.ObjectCollection's constructor (well, one of three constructors, since it's overloaded) looks like this in VB:

Public Sub New( _
   ByVal owner As ListBox, _
   ByVal value() As Object _
)

This suggests to me not that there are copies of the values, but rather copies of the value of the pointer. I can't think of any other possible interpretation, since otherwise we have to know more than we do at the time of construction about the type of object that's going to be pointed to.

Do you agree with that, Rick, or am I missing something?

Bob

 

[ThatRickGuy]

Actually, I would infer just the opposite. Since we are passing in the variable by Value we are passing a copy of the value (ByVal vs ByRef).

Also, everything is an object in .Net. A string, an integer, a bitmap, a stream. So an object collection could contain strings, data row views, custom objects, or what ever else you want to put in it.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[BobRodes]

Ok to your second, curious about your first. What value are we passing to the constructor, if the type is an object? I thought it would be the value of the pointer to the object.

 

[ThatRickGuy]

Public Sub New( _
   ByVal owner As ListBox, _
   [b]ByVal[/b] value() As Object _
)

The ByVal indicated that we pass a duplicate of the value.

If it were:

Public Sub New( _
   ByVal owner As ListBox, _
   [b]ByRef[/b] value() As Object _
)

we would be passing the reference of the value.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[BobRodes]

Rick, I believe it runs a little deeper than that. I did some digging around, and here's a quote from a book (Balena: Programming Microsoft Visual Basic.Net):

Whenever you pass a value type to a method that takes an object argument, the value is converted to a reference type: the .NET runtime allocates a block of memory in the managed heap, copies the value in that area, and passes the method a pointer to that memory location.

In other words, the value is boxed (if necessary) on account of the argument type being an object, and what is actually passed is the pointer to the object containing the value, whether the argument specifies ByRef or ByVal.

While you're certainly one of the most knowledgeable people here, this explanation appears correct, and it's not clear to me that it's consistent with yours. Am I missing something, or is this a case of Quandoque dormitat bonus Homerus (even the great Homer nods)?

Bob

 

[ThatRickGuy]

You are correct. Most people don't worry about the actual memory value that is sent to the method. The key thing to be concerned with is that if you pass a value ByVal the original variable is not effected by anything that happens to the value you passed into the method. But if you pass a value in ByRef, it will be. For example:

public sub main
  dim x as integer = 0
  dim y as integer = 0

  DoThingByVal(x)
  DoThingByRef(y)
  msgbox("X: " & x & environment.newline & "Y: " & y)
end sub

Public sub DoThingByVal([b]ByVal[/b] Value as integer)
  Value += 1
end sub

Public sub DoThingByRed([b]ByRef[/b] Value as integer) 
  Value += 1
end sub

(untested)

When you run this, you will see a message box that says:

X:0
Y:1

Yes, no matter how you pass the value, at the compiler level only a memory address is passed. But passing by value creates a duplicate of the value in memory, then passes that value's memory location. ByRef passes the memory location for the original value.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[BobRodes]

<if you pass a value ByVal the original variable is not effected by anything that happens to the value you passed into the method. But if you pass a value in ByRef, it will be.

See, that's not quite true, and I can't tell if we don't agree or if we're miscommunicating. It's only true with respect to passing values to variables. It is NOT true when you pass references to variables. Whether passed ByRef or ByVal, a reference is still a reference.

If you take your above code and put a class as the argument instead of an integer:

public sub main
  dim x as new myClass
  dim y as new myClass

  x.myProperty = 0
  y.myProperty = 0

  DoThingByVal(x)
  DoThingByRef(y)
  msgbox("X: " & x.myProperty & environment.newline & "Y: " & y.myProperty)
end sub

Public sub DoThingByVal(ByVal Value as myClass)
  Value.myProperty += 1
end sub

Public sub DoThingByRef(ByRef Value as myClass) 
  Value.myProperty += 1
end sub

(also untested in .Net, tested in VB6)
When you run this, you will see a message box that says

X:1
Y:1

Furthermore, all the books back up this point of view. Here's another quote (from Pattison: Building Applications and Components with VB.Net):

How does changing the parameter to a reference type affect what happens at runtime? Your intuition might tell you that you are passing a copy of the object by value because you have used the ByVal keyword. In reality, this is not what happens. The CLR creates a copy of the reference, not the object. Both the caller and the method have their own private copies of references that point to the same object. This the method sees the same object as the caller, and this method can make modifications to the object that can be seen by the caller.

So, I say an object reference passed ByVal works exactly like an object reference passsed ByRef, as far as behavior is concerned. The only difference is that in ByRef, each variable uses the same copy of the reference, and in ByVal, each variable gets its own copy of the reference.

As I said, I haven't been able to tell whether you agree with this or not--maybe you've been talking about stack variables all this time and I've been talking about heap references. So, what's your take on this?

I'm particularly curious to know how this plays out where strings are concerned, and why. In VB6, passing string arguments ByVal to an API call would allow the mod of the string for basically the same reason described in this quote.

Thanks,

Bob

 

[ThatRickGuy]

I don't have .Net on this machine, but that sounds correct. I seem to remember reading the same thing a few years ago.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.