Good evening folks, I'm new here and I hope someone can give me some extra insight into my current situation.I'll try and be as complete and to the point as possible in describing my situation.Basically I have a Windows Form UltraWinGrid which I'm populating with List<T>, however, I wish to replace several id-fields by their respective description fields.Let's scetch my situation with a simple example.Say I have a List<Customer> and the Customer class includes the usual properties like name, first name, birth date, ...But also various id fields. The Customer class is a object that gets it's data filled from OR mapping from a persistent storage medium, in my case that's a SQLServer2005 database, the id fields are basically the relationship fields from the database. Basically Customer object is pretty much an object representation of the persistent table.So for example:public class Customer{ String name, firstName, PhoneNumber, ... int customerId, favColorId, livingPlaceId}public class FavoriteColors{ int favColorId string colorName, hexNotation, string RGBNotation}public class LivingPlace{ int livingPlaceId string country, city, countryCode, postalCode}So I have a List<Customer> customers and bind it to my grid in code behind as 'customersGrid.Datasource = customers'This works fine and my whole system has already been programmed around working like this. So for functionality there's no problem. After all, it's the id values that are used for the programmatic identifying and so on.However like this I display values to the user that he wouldn't really understand as the first record would for example be CustId Name FirstName Phone FavColorId LivingPlaceId1 Me Me Again 2211 1 1So when displaying the grid I would like FavColorId to be replaced with it's colorName with that Id. The same for livingPlace, I'd want the grid to show country for example with that stored id.For this example let's assume the values are stored in a List<FavoriteColors> and a List<LivingPlace>.That's what I'm seeking to accomplish in a nutshell. I was thinking of adding an unbound column for each id-field (in code) after setting the datasource to customers (haven't looked it up yet, but that should be possible right?), and afterward I'd go through the whole grid with a foreach(UltraGridRow in grid) loop, filling the unbound columns with the looked-up data.And then I'd hide the columns that the user doesn't actually need to see.However, I suppose that'll be rather performance ineffective, so was wondering what you folks think of this.Ok, I think that's about it.
Hi,
This is a very common scenario and it's very easily handled. What you want to do here is use the ValueList property of the column in the grid to attach a list of data and display values to the column. The grid will take care of the rest - translating the data value into a user-friendly display value for the user to see while still keeping the data value in memory and saving it to the data source.
There are two kinds of ValueLists you can use. One is the ValueList class and the other is the UltraDropDown. This KB article will give you more information about how to set it up and which one is right for you:
HOWTO:What is the best way to place a DropDown list in a grid cell?
Mike,
Hmmmm. Any other ideas.
Your suggested method doesn't appear to be working for me. Something must not be right, but Ican't tell what it is because Infragistics Control logic is not throwing an exception.
Regards,Rob
Hi Rob,
Yes, that's correct. You can't have a dropdown list and FormattedText in the same column.
Hello Mike,
Yes, and without the control throwing an exception, who would know?
What if all of the values in the ValueList were of a Decimal data type, that the user wished to display formated as a Currency. Wouldn't the user be tempted to set the Column Style property for Currency? Sounds reasonable to me.
R.
Maybe, but the grid can't throw an exception in this case. Setting the ValueList on a column and setting the Style do basically the same thing. So whichever one you set last overrides the other. There's no way the grid can know that you intended them to work together.
Well Mike, I cannot really follow your assessment that these two property settings do essentially the same thing, as one is a type of embedded data source, and the other is not. They cannot possibly do the same thing.
Additionaly, they are both properties of the Infragistics.Win.UltraWinGrid.UltraGridColumn class, and as such aught to enforce some sort of data integrity between each other, if any dependency exists. One would think, anyway. Certainly, it is feasible to perform validation checks at run time, if such could not be performed at design time.
Lastly, your premise that “what is set last overrides the other” does not follow here either. In the code I worked with, the Style property was set first, and those settings having to do with the ValueList were performed afterward.
Look Mike, I appreciate the work Infragistics has done to extend the functionality of .Net controls. Now the controls are so heavily layered and overloaded, I am not surprised that the wires get crossed. Still, issues like this are costly in the time and money my team spends trying to decipher mysterious behavior, rather than advancing the development of our software.
roblove said:Well Mike, I cannot really follow your assessment that these two property settings do essentially the same thing, as one is a type of embedded data source, and the other is not. They cannot possibly do the same thing.
What they both do is determine what editor the column uses. Setting the Style to FormattedTex, for example, is the same as assigning an UltraFormattedTextEditor to the EditorControl property of the column. Except that in the former case, the grid creates an editor internally and in the latter case, it gets the editor from the FormattedTextEditor control. Similarly, setting the ValueList on the column assigns an EditorWithCombo to that column, because the EditorWithCombo is the editor that has a dropdown list in it.
roblove said:Look Mike, I appreciate the work Infragistics has done to extend the functionality of .Net controls. Now the controls are so heavily layered and overloaded, I am not surprised that the wires get crossed. Still, issues like this are costly in the time and money my team spends trying to decipher mysterious behavior, rather than advancing the development of our software.
I can understand the confusion. You are right, this behavior is a result of the fact that the control did not originally support editors and now it does. But unfortunately, that's the price for adding lots of new features over the years without breaking backward compatibility.
And that's why I'm here answering forum posts all the time - to help clear this stuff up.