It all depends. If all you have is a form which asks for user input, then exposing those inputs as properties would be straightforward even from a OO perspective. If your main form will interact a lot with a child form, then you could declare the child form as a private member of the owner and, whenever the child raises an event, you could access it locally, requiring no casting.
Of course your suggestion works in all cases (that is why I gave it a 5). But in some situations we don't need an absolute loose coupling. As I said, it always depends on the situation.
1. Public properties in the object that raises an event is another way. The downside is (to handle this correctly) you would need to use the sender parameter in the handler and cast it to the correct type to have access to those properties. Having them in the args is cleaner. Remember, the subscriber can use one handler for many events from different objects so long as the signatures are the same. Your suggestion makes that unworkable.
2. A bad idea due to the coupling created between objects. I would always avoid this!
3. Just to pass text it is maybe sometimes a little overkill, but using this principle any amount of data can be passed in one go.
Your suggestions are valid but, in my opinion apart from very simple situations that will never need to change with scope creep, not as useful or as observing of OOP principles.
Last Visit: 31-Dec-99 18:00 Last Update: 25-Oct-14 13:54