PC Review


Reply
Thread Tools Rate Thread

Design Question regarding Events

 
 
Paul Hadfield
Guest
Posts: n/a
 
      23rd Jan 2007
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'd really appreciate some thoughts / comments on the above to make sure I
don't end up going down the wrong path.

Regards,

- Paul.


 
Reply With Quote
 
 
 
 
Larry Lard
Guest
Posts: n/a
 
      23rd Jan 2007
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
 
Reply With Quote
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Form close events and design view Jeff Hunt Microsoft Access Form Coding 4 7th Aug 2008 05:06 PM
Design time events Josh Sale Microsoft Excel Programming 2 3rd Dec 2004 07:39 PM
Why controls can't receive the mouse events in design-time? Jerry Microsoft C# .NET 0 6th Jul 2004 02:27 AM
Design - Detect mouse events on a region Chrome Microsoft VB .NET 0 3rd Feb 2004 02:52 PM
Re: Basic table design - design question John Vinson Microsoft Access Getting Started 1 26th Jun 2003 05:22 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 07:43 PM.