>>>>>It is stored as an int in the table.
>>>>>
>>>>>I use MM.NET and this binds the combo to a BO so I don't actually manually set the datasource.
>>>>>
>>>>>I don't quite follow your suggestion (I'm still a baby when it comes to this .NET C# stuff and the terminology), but if you don't have the time to explain further, no problem as Bonnie's suggestion has worked for me.
>>>>
>>>>OK. I'm confused as to how the ComboBox.SelectedValue ends up as a string in that scenario - but as long as its working.......
>>>>( I assume you tested this with non-matching descriptions ?)
>>>>
>>>
>>>Hi Viv,
>>>
>>>It is MM magic where additional properties are added to the controls that allow binding for both the table that drives the display as well as the value and synchronizes to the child table where a foreign key is stored. I suspect the problem Frank was solving was how to know or compare the value for some other purpose other than or before the mm save was taking place. I don't really know if using a enum made this more complicated or not but he will certainly need to keep his enum values syncrhonized with the table driven values as well because of it.
>>
>>What I didn't (and still don't) understand is:
>>(a) Frank says an int is used to store the enum value in the Lookup table.
>>(b) This table is the DataSource for the combo box.
>>(c) But..... the SelectedValue of the ComboBox is a string representation of an integer.
>>(which means that to compare it against any enum value the enum itself has to be converted to an int and then to a string.....)
>>So why/where did the .SelectedValue become a string ?
>>
>>In that situation then using an enum is certainly more complicated than it need be......
>>Anyway, not important since it works and Frank's happy :-}
>
>Mere mortals has 5 other properties that are used for the binding and syncrhonizing process rather than the selectedValue or DataSource.
>BindingSource is the business object for the lookup table
>BindingSourceDisplayMember is the column in that business objects table you want to be displayed.
>BindingSourceValueMember is the (int this case) that represents the primary key from that table or the value you want to use to store as the foreign key in the child table
>BindingValueSource is the business object (table) for the child where you want to store the selected value to.
>BindingValueSourceMember is the child tables foreign key field.
>
>These are all synchronized with other properties in the framework such as setting the DataSource property and navigating to the selectedValue when the child table has a value already. There are some conversions that go on but not sure if the values are converted in this instance where the SelectedValue is concerned.

These are properties of MM's derived ComboBox class? But I'd assume that BindingSourceValueMember would map to the underlying ComboBox.ValueMember - iac that's what Frank was checking.

>This functionality in the framework is seperate from what Frank is trying to do with his enums but could be a factor. I am not sure as I haven't checked if the int value set in the BindingSourceValueMember is converted and used in the SelectedValue or not or if he is setting it. I have not seen or noticed why Frank needs to compare the selected value but with a table driven values in the combo ( a good design) and then synchronizing with an enum makes it a bit fragile. There may or may not be a different way to do it but I am not trying to judge his choice. It might be a good idea for understanding to look in the mm Control to see what native properties are used in conjunction with the mm properties and how they are handled, but then again if he found a resolution he should be on his way.

I'd argue long and hard for the use of an enum in this sort of thing: convert to an enum as soon as the table value (int,byte whatever) is retrieved and only convert back when the value needs to be committed to the backend. No magic number or casting required (or allowed) *anywhere* outside the layer closest to the DB.
Using an enum certainly doesn't make things any more 'fragile' - any alternative scenario (constants, etc) is more open to that accusation. And if you have a 'flags' enum type requirement then multiple the benefits of enums by 10......

But I can't argue now - work to do :-{