Paul Hadfield wrote:
> I'm looking for input / ideas on the following design problem:
>
> As an example for the business layer, there is a class "DataObjectHandler"
> with one method "Get()" that returns an initialised list of the class
> "DataObject". It also contains a method "Add(DataObject)" This adds the
> passed DataObject to the list and fires a "ListChangedEventHandler" event
> handler informing any subscribers that the list has changed (the event args
> contains the newly updated "DataObject" list).
>
> For the UI I have a simple form with two combo boxes (combo1 and combo2) and
> a corresponding "Add New" button (AddCombo1Btn and AddCombo2Btn) for each
> combo box respectively. The method "UpdateCombo1" subscribes to the
> "DataObjectHandler.ListChangedEventHandler" and updates combo1 list with the
> new list supplied in the event args. A corresponding method "UpdateCombo2"
> does the same, but for ComboBox2.
>
> Clicking on either button creates a new DataObject and passes it to the
> "DataObjectHandler.Add(DataObject)" method. This in turn fires the
> ListChanged Event, which in turn updates both combo boxes (as they both
> subscribe to the event).
>
> I've got this up and running and it appears to work fantastically, clicking
> either "add" button updates both combo boxes with the new list. However
> there is an additional requirement that if "AddCombo1Btn" fires the event
> then as well as updating both lists, the selected item for "combo1" should
> become the newly added "DataObject" (but the selected item for "combo2"
> should stay "as is"). Accordingly if "AddCombo2Btn" fires the event, then
> the selected item for "combo2" should be updated, but not "combo1".
> Technically the solution should scale in that the each list / button pairing
> maybe on different forms (but obviously sharing the same instance of
> "DataObjectHandler")
>
> I can think of two solutions.
>
> The first is an additional method DataObjectHandler.Add(DataObject,
> List<ComboBox> comboBoxes). The 2nd parameter contains a list of the
> comboboxes who's selected item should be updated to match the newly added
> DataObject. This would be added to the event args so it is passed back to
> the subscribing methods (whose responsibility it would be to check that
> list).
>
> The second solution would be to update the tag property of the combo box
> that corresponds to the "Add" button clicked, this would occur just before
> the DataObjectHandler.Add(DataObject) call. This seems to be the cleaner
> solution as it doesn't need anything to be passed through the event handler
> and back. Of course, I could extend the combo box class with a specific
> flag if using tag wasn't ideal.
I would agree with your feeling that this is infromation that shouldn't
concern any layer other than the UI; so, don't change the message. I . I
would be inclined to give the combobox a new property (whether formally
by subclassing, or just jimmy it into the Tag) which means 'when an item
is added, does it become the selected item'. Then Button1's code looks like:
Set this flag to true on the combo
DataObjectHandler.Add
Set this flag to false
whereas Button2's code is just
DataObjectHandler.Add
DataObjectHandler itself remains blissfully unaware of the UI behaviour.
There might be threading issues if you have multiple threads
--
Larry Lard
(E-Mail Removed)
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version