Comments and Discussions
|
|
Reason for my vote of 2
While it works in principle, it tightly couples forms together and having multiple subscribers to an event soon becomes unworkable
|
|
|
|
|
Reason for my vote of 1
noob
|
|
|
|
|
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.
|
|
|
|
|
Reason for my vote of 3
See my comments below.
|
|
|
|
|
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.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
Submit an article or tip
