Hi guys,
Thanks for taking the time to read my post.
I’ve run into a weird programming challenge that occurs when I need to bind a property, that gets/sets a child object, to a combo box. This situation occurs in multiple places throughout my business objects and my UI. I suspect many of you guys have also run into this and I’m hoping you can offer some suggestions.
Here's an example - I have an editable “Payment” object with a child “Type” (payment type) object…
PAYMENT, editable parent object:
- Id (read only property, integer)
- Amount (editable property, decimal)
- Type (editable property, business object)
- other editable properties
TYPE, read only child object:
- Id (read only property, integer)
- Description (read only property, string)
- other read only properties
I am binding all of the Payment object’s properties to Windows form controls to eliminate as much UI coding as possible. It’s worked fine for properties that are strings or numbers, like “Id” or “Amount” – I bound them to a textbox and I was done (no UI code!). But then I looked at binding the “Type” property (object) to a combo box and things got ugly.
I am populating the “Payment Type” combo box using a separate CSLA Name-Value-List object that contains the Ids and Descriptions for the various payment types. I bound the combo box’s “SelectedValue” property to Payment.Type.Id – this binding made it so that when the object is changed, the combo box automatically changes itself to whatever payment type is selected in the object. BUT, the change relationship does not work in reverse – a change to the combo box does not update the object. That doesn’t work because the combo box selects an integer (type id) and the payment object’s “Type” property gets/sets a “Type” (payment type) object. So I am forced to write one line of code (oh no!) in the combo box’s “LostFocus” or “SelectedIndexChanged” handler to instantiate and assign a new object to the “Type” property.
I’m trying hard to make it so our UI developers write as little code as possible. So I really want to get rid of that one line of code! I’ve explored various solutions to eliminate this line of code, all of which I do NOT think are very clean or elegant. The best of the bad solutions I’ve come up with is this…
I’m considering adding a new editable property to the Payment object called “TypeId” (integer). Then I’d change the original “Type” property (object) to be read only. I still want to keep the original “Type” property (object) because its data is used for display purposes other UI screens. My thought is that the new editable “TypeId” property (integer) will not only change itself but, behind the scenes, it will also change the original “Type” property (object) too. Then I’d bind to combo box to the new “TypeId” property (integer) and changes would then be affected in both directions – object to combo box and combo box to object.
However…
The nit-picky, anal-retentive side of me does not like the fact that there is going to be somewhat duplicate properties…..Type and TypeId.
Has anyone else run into this and thought of a more elegant solution?
Thanks,
Jason
Or has anyone run into this same problem and resolved it the same way I did?
Or have I done something weird with my object design and created a situation that should not ever occur? (the unusual lack of responses makes me concerned about this)
Jason
Copyright (c) Marimer LLC