Can someone explain to me what's going on here...
I'm populating a grid based on a value selected in a stand alone UltraCombo. When opening the form I would like to initialize the combo with the most common selection and thus populate the grid with data.
Performing SetInitialValue automatically calls the ValueChanged event - which is great.
If I designate my ultracombo to be of style "DropDown" the following code runs fine - meaning that, in the ValueChanged event, the value has a valid value. However, if I simply change the style to "DropDownList" the ucChooseVendor.Value is null.
I had initially setup a bunch of forms with the style being DropDown (the default) but realized that the user could type text within the dropdown which I did not want - so I changed them to DropDownList style.
PS #1: Is there a way to have a DropDown style and yet prevent them from changing the list items (i.e., typeing) in the control?
PS #2: I also noticed that with the DropDown style, when I type bogus info into the combo the ucChooseVendor.Value is the value of the bogus data rather than say maybe null or -1. In other words, why now all of a sudden, does the control want to return the DisplayMember vs the ValueMember?
All-in-all, somewhat confusing behavior in my opionion.
Thanks,
Mark
private void form1_Load(object sender, EventArgs e)
{
.....other code here....
}
e)
....
DataTable dt = DataLayer.Vendors.GetGLAccountVendorItems(ucChooseVendor.Value.ToString()); // <= Value is Null here depending on style
)
In DropDownList mode, only values that exist on the list are valid. So my guess is that you are calling the method before you have populated the list and so the Value of the control is getting set to null because the Value you are trying to apply is not on the list.
SetInitialValue is designed to circumvent this scenario a little bit, by delaying the application of the value until someone asks for it. But if you ask for the value when the event fires and this occurs before the list is populated, it won't work.
There are a number of ways you could get around this. One way would be to populate the list first and then simply set the Value property on the control (you don't need to call SetInitialValue in that case).
Another way would be to move the code that populate the grid into a method and cal that method both from the ValueChanged event of the Combo and also in the Form_Load or some similar event to force the loading of the grid with the default data you want.
>>So my guess is that you are calling the method before you have populated the list and so the Value of the control is getting set to null because the Value you are trying to apply is not on the list
That's not the case...here are two screen shots in debug mode (I hope you can see them). The first is when it is set to DropDownList and the value is NULL. The second is after I simply went to the GUI and changed it to DropDown style - the value has the correct GUID value.
In each instance, the ValueChange event is not called until I SetInitialValue - confirmed with the breakpoint setting.
>>One way would be to populate the list first and then simply set the Value property on the control (you don't need to call SetInitialValue in that case).
And thus, the whole reason why I am attempting to use SetInitialValue in the first place. Setting the value displays a Guid (the actual value) rather than the friendly text (DisplayMember).
One hack that I tried was to simply set the DropDownStyle in code after SetInitialValue as such:
ucChooseVendor.DropDownStyle = Infragistics.Win.UltraWinGrid.
UltraComboStyle.DropDownList;
Even though the dropdown intially displays the correct friendly value on startup the combo value is null when inspected in a button click.
It's not that I won't be able to find a work-around - my point of the post is that if I set the initial value to something valid I should subsequently be able to retrieve that value using ucChooseVendor.Value - regardless of a simple dropdown style settings.
Thank you Mike...
Oh, I see. I wasn't looking closely enough at the dates. I see that your last reply was back in June. And you are right, of course, akaBd had no way to know this was fixed. Now my confusion is all cleared up. :)
Anyway... NOW there's an indication that this is fixed. :)
But to be fair to akaBd...there is no indication that this thread has a resolution other than our most recent posts and you stating that the bug has been fixed. Might be a good idea to have a way to link posts/threads to bug identification/resolution.
Thanks Mike
>>and you replied thanking her.
That's correct.
>>So... why are we still discussing this issue?
ummm...I don't know...ask akaBd. Maybe he's just trying to rack up some points :)
Hi,
Okay... I'm really confused, now. Maybe this thread has just gotten so long I can't remember it all.
I just checked, and according to our records, this was written up as a bug by Brian and I fixed it back in July. There are two separate Developer Support Cases associated with the bug (both from you).
One August 30th, Asma, who was handing one of these cases notified you the the issue was fixed and you replied thanking her.
On August 31st, Stefaniya, who was handling the other case, notified you of the fix a second time.
So... why are we still discussing this issue?
check types
for combo items and your 'dummy' it's must be the same
string = string
but string != object