I'm a bit confused right now. It's taken a while to narrow down my problem, and it doesn't make sense. I'm binding a list of simple objects to an UltraComboEditor. There's nothing particularly special about the items, or the editor itself. I have manually set the DisplayMember and ValueMember properties, and bound the list. Depending on whilch machine I run on, I get inconsistent behavior from the control. On my dev box (Win7 64 bit, VS2010) I get the proper response back for the Value property of the control. That is, I get the Id property back from the item, since that is what I set as the ValueMember property of the control. On my neighbor's identical machine, he gets back a string which we've determined corresponds to the first alphabetical property of the bound object. This is the same code. I mean exactly the same code. If I build it on his machine, the control returns one thing. If I build it on my machine I get something else.
I thought at first that the presence of a previous version of the controls (2009.1) on his machine might have been the problem, but I have it on my machine, too. I found references to the 2009.1 versions of the controls in the .licx file, so I removed them, and the problem remains.
I am, quite frankly, at a loss. I "Get Latest" to both machines (using TFS), and build... different behavior. Any help/clue would be appreciated.
Are you sure you are setting the ValueMember property and that it is not getting reset somewhere in the code? If ValueMember is not set, then the Combo falls back to using the first column in the data. This would explain what's happening in your case, because the data source returns the data in an arbitrary order. In fact, I have personally encountered issues like this where the BindingManager in DotNet returns the columns in a data source in a different order on different machines. In my case it was because the machines in question have different versions of the DotNet Framework installed and were running different operating systems.
I'm very certain that ValueMember is set. I even changed how it was being done from in-code to in the designer to see if it would make any difference, and it didn't. It also wouldn't explain why builds made on one machine would work differently than builds on another. The only explanation I can think of for that is a known bug that is fixed on one installation and not the other, but both machines had the same setup there as well. They're both using v10.2, and had a previous v9.1 still in place.
The default binding behavior is the really confusing part. I had tried to look up related issues and saw other posts about how the control will display the first property if none is specified, and that is what I'm seeing. But since I have set a ValueMember, this shouldn't be happening.
I've worked around the problem for now by binding ValueMember to a different property, and that one seems to work fine. It was unhappy with the generic "Id" property that all our entities expose, but was perfectly happy with the entity-specific "SignatureCardId" property that backs it. The only appreciable difference between these two is that the generid "Id" property is exposed as a decimal whereas "SignatureCardId" is an integer. There's a story behind this, but it's too frightning to share, even in October.
I'm afraid I am at a loss to explain this. My best guess is that the two machines have different versions of the DotNet framework, or perhaps different version of whatever database engine you are using, and so this is causing different behavior.
You said both machines are using v10.2. So they both have (or not have) the latest service release?
Have you tried checking the ValueMember/DisplayMember on the control at run-time? I'd try it in a button_click event or something like that, just to be sure it's still set to what you think it is.
Another thing you might try, just as a test, would be to bind a WinGrid to the same data source you are using for the UltraComboEditor's list portion. This will give you a visual indication of the order in which the columns are being returned from the data source.