CA1009
-
I'm not; an
eventhas two arguments; the object that raised the event, and some event-specific arguments derived fromEventArgs. It's a predictable pattern.Ennis Ray Lynch, Jr. wrote:
My events are usually specifically typed to the objects that throw them. Yes, yes, that does couple the events tightly to the objects but ... no one should have to check the type of sender before using it, that design is even worse.
I'd rather not have separate click-events for a
Button.Click and aMenuItem.Click.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Eddy Vluggen wrote:
I'd rather not have separate click-events for a
Button.Click and aMenuItem.Click.If you're using .NET 2.0 or higher, delegate contravariance[^] means that you wouldn't need separate handlers; you can assign a method which accepts an
objectas a parameter to a delegate where the corresponding parameter is any reference type.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Eddy Vluggen wrote:
I'd rather not have separate click-events for a
Button.Click and aMenuItem.Click.If you're using .NET 2.0 or higher, delegate contravariance[^] means that you wouldn't need separate handlers; you can assign a method which accepts an
objectas a parameter to a delegate where the corresponding parameter is any reference type.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
you still need to declare one event per object, even if you can use the same method to handle them.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
you still need to declare one event per object, even if you can use the same method to handle them.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
All Mouse Click events come from the Control base type. To argue that object is better than Control? Funny. Further,
public delegate void SomeDeletage(T t);
public event SomeDeletage Foo;Looks pretty good on paper.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
All Mouse Click events come from the Control base type. To argue that object is better than Control? Funny. Further,
public delegate void SomeDeletage(T t);
public event SomeDeletage Foo;Looks pretty good on paper.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
What about events that come from FrameworkElements or DependencyObjects?
-
All Mouse Click events come from the Control base type. To argue that object is better than Control? Funny. Further,
public delegate void SomeDeletage(T t);
public event SomeDeletage Foo;Looks pretty good on paper.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Ennis Ray Lynch, Jr. wrote:
All Mouse Click events come from the Control base type.
Until someone comes along and makes me use a third-party library that doesn't.
Ennis Ray Lynch, Jr. wrote:
To argue that object is better than Control?
We're not talking "better", but "more generalized". Anything (derived from object) can throw an event.
Ennis Ray Lynch, Jr. wrote:
Looks pretty good on paper.
Isn't there an EventHandler<T> somewhere?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
I'm not; an
eventhas two arguments; the object that raised the event, and some event-specific arguments derived fromEventArgs. It's a predictable pattern.Ennis Ray Lynch, Jr. wrote:
My events are usually specifically typed to the objects that throw them. Yes, yes, that does couple the events tightly to the objects but ... no one should have to check the type of sender before using it, that design is even worse.
I'd rather not have separate click-events for a
Button.Click and aMenuItem.Click.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Eddy Vluggen wrote:
an
eventhas two arguments; the object that raised the event, and some event-specific arguments derived fromEventArgsThat's not true of all events; certainly not of ones I write. I even write events that return values, because it makes sense to do so for them. I really dislike Microsoft telling me how I should write my code :mad:
-
Ennis Ray Lynch, Jr. wrote:
All Mouse Click events come from the Control base type.
Until someone comes along and makes me use a third-party library that doesn't.
Ennis Ray Lynch, Jr. wrote:
To argue that object is better than Control?
We're not talking "better", but "more generalized". Anything (derived from object) can throw an event.
Ennis Ray Lynch, Jr. wrote:
Looks pretty good on paper.
Isn't there an EventHandler<T> somewhere?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
My rant is more, I would much rather have the typed event. Your third party library can use what ever it wants. I was just ranting that the "preferred method" is object sender.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
Eddy Vluggen wrote:
an
eventhas two arguments; the object that raised the event, and some event-specific arguments derived fromEventArgsThat's not true of all events; certainly not of ones I write. I even write events that return values, because it makes sense to do so for them. I really dislike Microsoft telling me how I should write my code :mad:
I learn a lot by looking at best practices. For example, I actually changed the way I code based on this
if(foo.Equals("bar"))
is worse than
if("bar".Equals(foo))
Can you guess why?
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
I learn a lot by looking at best practices. For example, I actually changed the way I code based on this
if(foo.Equals("bar"))
is worse than
if("bar".Equals(foo))
Can you guess why?
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
if (foo == null) throw new NullReferenceException();
?
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Eddy Vluggen wrote:
an
eventhas two arguments; the object that raised the event, and some event-specific arguments derived fromEventArgsThat's not true of all events; certainly not of ones I write. I even write events that return values, because it makes sense to do so for them. I really dislike Microsoft telling me how I should write my code :mad:
PIEBALDconsult wrote:
That's not true of all events; certainly not of ones I write.
It wasn't about you; like I said, it's a generalization.
PIEBALDconsult wrote:
I even write events that return values, because it makes sense to do so for them.
That'd be called a "callback", not an event. Would it not be an advantage to "define" an event as "something" that passes an
EventArgs? Sounds like a simple pattern to me; a pointer to sender, and a pointer to the arguments.PIEBALDconsult wrote:
I really dislike Microsoft telling me how I should write my code :mad:
Even if they would, you would not listen. I'd recommend to most other people to consider multiple points of view, but not with you*. You have your own view, and sometimes it pays to have YOU tell how I should write my code. Have a good 2013, I hope to disagree with you* more often.
*Learn from you
-
I learn a lot by looking at best practices. For example, I actually changed the way I code based on this
if(foo.Equals("bar"))
is worse than
if("bar".Equals(foo))
Can you guess why?
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Sure. Yet if foo is a string then the
==operator is best (in C#). There should be very few times where you need to call Equals directly.Ennis Ray Lynch, Jr. wrote:
best practices
In my experience, most "best practices" aren't good practices.
-
PIEBALDconsult wrote:
That's not true of all events; certainly not of ones I write.
It wasn't about you; like I said, it's a generalization.
PIEBALDconsult wrote:
I even write events that return values, because it makes sense to do so for them.
That'd be called a "callback", not an event. Would it not be an advantage to "define" an event as "something" that passes an
EventArgs? Sounds like a simple pattern to me; a pointer to sender, and a pointer to the arguments.PIEBALDconsult wrote:
I really dislike Microsoft telling me how I should write my code :mad:
Even if they would, you would not listen. I'd recommend to most other people to consider multiple points of view, but not with you*. You have your own view, and sometimes it pays to have YOU tell how I should write my code. Have a good 2013, I hope to disagree with you* more often.
*Learn from you
Eddy Vluggen wrote:
it's a generalization
Yes, but it shouldn't be enforced by the compiler. I wouldn't want the compiler to dictate where I should put whitespace either. :badger:
Eddy Vluggen wrote:
"callback", not an event
The syntax says
eventso that's what it is; but that's really just a type, conceptually it could be a callback. Just as an int could be an ID or an index. I wouldn't see a need to have two keywords for such similar concepts. Come to think of it, this is really like the difference between functions and procedures -- functions return a value and procedures don't -- some languages (Pascal and VB for instance) make the syntactic distinction and others (C-like languages for instsance) don't, and I agree with the C way of doing it. As an aside: VB doesn't allowevents to have a return value. :sigh:Eddy Vluggen wrote:
it pays to have YOU tell how I should write my code
I hope I don't do that. :-O CP is definitely a great place to get many points of view from others with varied experiences. <voice type="MOB" >I say this thing with the greatest respect</voice>
-
Sure. Yet if foo is a string then the
==operator is best (in C#). There should be very few times where you need to call Equals directly.Ennis Ray Lynch, Jr. wrote:
best practices
In my experience, most "best practices" aren't good practices.
I may not like or use best practices but I at least consider them (although most people assume I don't), I may have picked a poor example for my case but the point was more, hey there are some good recommendations, even if the vast majority are crap. And, with regard to string "best-practices" I have since moved away from the "constant".equals(obj) to String.Compare(val1, val2, true [or false]) == 0 which I think is more better considering that maybe one day I may actually have to use multiple language support.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
I may not like or use best practices but I at least consider them (although most people assume I don't), I may have picked a poor example for my case but the point was more, hey there are some good recommendations, even if the vast majority are crap. And, with regard to string "best-practices" I have since moved away from the "constant".equals(obj) to String.Compare(val1, val2, true [or false]) == 0 which I think is more better considering that maybe one day I may actually have to use multiple language support.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Ennis Ray Lynch, Jr. wrote:
I at least consider them
Absolutely, you need to know your options to be able to choose one intelligently and understand the code of others.
Ennis Ray Lynch, Jr. wrote:
String.Compare
Oh, well then I'm a fan of
StringComparer.InvariantCultureIgnoreCase.Compare ( string , string )and it's ilk. Have a property or parameter of type StringComparer so the caller can provide an appropriate instance to use. :cool: -
Eddy Vluggen wrote:
it's a generalization
Yes, but it shouldn't be enforced by the compiler. I wouldn't want the compiler to dictate where I should put whitespace either. :badger:
Eddy Vluggen wrote:
"callback", not an event
The syntax says
eventso that's what it is; but that's really just a type, conceptually it could be a callback. Just as an int could be an ID or an index. I wouldn't see a need to have two keywords for such similar concepts. Come to think of it, this is really like the difference between functions and procedures -- functions return a value and procedures don't -- some languages (Pascal and VB for instance) make the syntactic distinction and others (C-like languages for instsance) don't, and I agree with the C way of doing it. As an aside: VB doesn't allowevents to have a return value. :sigh:Eddy Vluggen wrote:
it pays to have YOU tell how I should write my code
I hope I don't do that. :-O CP is definitely a great place to get many points of view from others with varied experiences. <voice type="MOB" >I say this thing with the greatest respect</voice>
PIEBALDconsult wrote:
Yes, but it shouldn't be enforced by the compiler. I wouldn't want the compiler to dictate where I should put whitespace either. [badger,badger,badger,badger...]
Good point :thumbsup:
PIEBALDconsult wrote:
I hope I don't do that. :O
Until someone offers something better, I'll be abusing your DAL. ..and the rest :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
