>>>I found the answer. See http://www.theproblemsolver.nl/dotnet_faq_0013.htm. It seems that the .NET framework has a quirk that the listbox is populated after a postback from the viewstate. Therefore if the value is not in the listbox when the postback occurs, it will not be there after the postback either. The solution is to add it explicitly before the postback occurs.
>>
>>
>>That's not a quirk.
>>
>>Thats a bug.
>
>
>I tend to agree but since I am a total newbie to .NET I wanted to be careful in my condemnation. I have found lots of things in .NET webforms that look and act like kindergarden compared to VFP. I really don't understand M$ when they have a great product like VFP and then try to replace it with something newer and worse.
>

I'd say it's neither if you understand why it's doing what it's doing. You'll run into this a lot with web applications under ASP.NET and viewstate. In some respects you can think of the viewstate as simply a client-side cache. Instead of it repopulating the list by hitting the database (which can be fairly expensive in time), it does it via a serialized representation of the data at the time the control was rendered (then deserializes it back on the server at postback). You don't need to hit the database everytime the page posts back (remember - the web is stateless; these controls need to be rebuilt on every postback). There's more to it than that, but this is one aspect of what it's used for). Sometimes the effect of this isn't quite what you want or expect, but it's baked into the design (you might curse it here but in other places it's what is making things "just sort of work like a desktop app").

You also can't really compare a web application to a desktop application. They are fundamentally different beasts, with different design constraints.