DropDownList doesn't carry correct Viewstate selectedIndex

[Phuff]

Apparently if you have any duplicates in your Value collection the
selected index that is maintained through the state defaults to the
first index in that group of duplicates.

So my items correspond to the Box_Id in the table (the unique
identifier in the DB). There are 8 boxes, 1-8. Then I grab a business
related date and fill the Value collection with this, that date
corresponds to something with each box. The dates (which become
values) could all be different or the same, there is no consistency
with the dates. Well boxes 1-6 all had the same recieve date so the
value was the same for all those items. Therefore, if you select
anything within "Index" 0-5 it will default to 0 because that is the
first item in the list with the duplicated date. Same for "Index" 6-7.
So when it is maintaining its state it remembers the selected index,
but won't allow duplicates in the value field. They should provide a
property which allows duplicates in the value field.

Is this a bug or intentional?

 

[Phuff]

This is all through a postback by the way

 

[darrel]

Is this a bug or intentional?

Just a WILD guess, but I assume viewstate for DDL's default to the value
field.

You may have to write your own check that grabs the selected index on
postback and reset it yourself.

-Darrel

 

[Jeff Dillon]

Sounds like you have a bad design to me. Why would you want duplicates in a
list anyway? Which one would the user want to select?? Very confusing. I
would say the behavior you are seeing is by design

Jeff

 

[Phuff]

Well, its simple. at the top you have a job order, which can have one
or more box units in it. Each box is a designed unit in an engineering
aplication (this "box" is something that gets built). They selected
the job already, and this is the page for when engineering received the
box. Lets say there are 5 boxes. It "could" be that engineering
received them over 5 days so each Recieve_Date could be different.
Also, they could have recieved each box in the same day, in which case
the Receive_Date would be the same for all.

On my drop down list the items (text which the user can see) is the
Box_ID. That is the unique identifier in the table and happens to be
the box's name as well. Thats what I want the user to see. With each
box is an associated date, which I grab from the database, and so I
don't have to reach into the database on every load I associated the
value for each item with its corresponding date. Yes, I can just
dynamically grab from the database, but is Progress and its old and
slow. Yes I can store the dates in an array and keep as a session
variable, I just found it wierd that I couldn't use the value
collection in this manner. It should maintain selected index despite
the values in the Item or Value collections.

 

[Jeff Dillon]

Yep, bad design. Using duplicate dates as a dropdown Value?? Um, why not use
the box_id as both the Text and Value?

Jeff

 

[Phuff]

Because I still need that date. Sure I could use the ID as both but
then I would need to make a call to the database when I need the date.
What I did was grab my dates and for loop through and place in session
variables that way I only needed to connect to the database on first
page load.

As far as the bad dplicate dates, I didn't realize it would be a
problem in the control. It took me a bit to realize the dates were the
issue. Some of these jobs will have a different date for each unit or
no date at all.

 

[Jeff Dillon]

You can put Objects in there too, not just scalar values. Put a struct that
has both box_id and date.

Jeff