|
Vaibhav Saran wrote: you bloody idiot, need not to post instructions if you dont know the answer.
I do know how to use the forums, which is more than you do. There are rules and guidelines for using the forums, and you don't seem to be aware of them. The first rule is post a question in the right forum - this is the .NET forum, not the ASP.NET forum.
If you have ASP.NET issues, then post them in the ASP.NET forum - that way your post will be seen by people who possibly have the answer for you. There is a reason, and as you seem to be a complete noob I'll explain it to you - the forums are searchable, so people are expected to search them for the answer to questions they have before posting a new question. This way, you can see the answer without having to post it and wait for others to answer. Now, suppose that a moron like you comes along and posts a question in the wrong forum - all of a sudden you can't get the answer you want in the forum you expect it in. You've got to start searching different forums, and that becomes wasteful. So you see, this is why you are expected to post into the right forum - and not to become abusive when you are pointed to the correct forum.
Still, if you want to trade insults sonny jim, you'll find that in a battle of wits, you're fighting unarmed.
|
|
|
|
|
Vaibhav Saran wrote: The person like are called "BEVKOOF" in india.
You could have looked to his profile before saying this.
He is a well respected MVP here in CP. Consider reading the forum guidelines before you post messages and try to respect others. People like you are spoling the name of indians.
|
|
|
|
|
Don't worry about it. I don't judge a nation based on the mewlings of an infant. I've worked with a lot of very smart, very talented Indians so I don't think he's representative. I'll just put it down to a misunderstanding.
|
|
|
|
|
So I am declaring a new event for a class and I get to the point where I need to define the event args. All I really need to pass through is a text string.
Now I usually follow some diligent best practice guide that I remember reading awhile ago that says you should define a new class to hold your event args instead of just passing the event data along in the class like so:
Public Event EventName (sender As Object, message As String)
So I do it like so:
Public Class EventNameEventArgs : Inherits EventArgs
Public Property Message() as String
End Class
Public Event EventName (sender as Object, e As EventNameEventArgs)
The problem is, I have the feeling that I am the only person on the face of the planet doing this  , but I have not seen any code form others that does NOT do this. I just want to get a general consensus for the group here...
I tend to think that yes, it is a good idea because it allows for the addition of new arguments latter on without breaking the existing code that references the event but...
Comments? Flames?
Please, no remarks about VB either...
|
|
|
|
|
Ray Cassick wrote: I have the feeling that I am the only person on the face of the planet doing this
You are not alone.
|
|
|
|
|
Hi,
i am just begginer, or intermediate.. I use user-defined events just like you, but i also create my own EventHandler to force using specific EventArgs
|
|
|
|
|
Ray Cassick wrote: The problem is, I have the feeling that I am the only person on the face of the planet doing this
No, you're not. The downside to NOT passing in a custom EventArgs is if you change the number and type of arguments that you send. If just passed, say, a String as an EventArg, then you needed to add another argument or change that String to an Integer, you'd have to rewrite the code for all instances of supplying the event args and all instances of a receiver of the event args.
When you create your own custom EventArgs, you just need to modify the EventArgs object, then update sections of code where you need to send and receive the changed/extra fields.
|
|
|
|
|
Good to know that I am not out of my mind
|
|
|
|
|
|
That is a really good article.
Thanks.
I really just wanted to make sure that I was not just following some standard that most other people thought was a waste of time.
|
|
|
|
|
You are welcome
|
|
|
|
|
This is the right way to pass information to an event handler. There are a lot of benefits to this approach, but the biggest ones are that if you need to add/change the data passed to the event you can do so without changing the event interface (which would break existing code). The only time this doesn't work well is when you change from using System.EventArgs to a custom event args class, but even that is a minor change.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Yeah, I know 
It's just a lot of repetitive work creating simple inherited eventargs classes just to send a simple text message back
Don't get me wrong, I always do it that way and see the value in it. I just recently have had to go through and create a bunch of classes that used really simple event arguments and was having a little 'crisis of faith' over seeing a ton of really simple EventAargs classes, one for each event.
I initially thought about just creating a simple BasicMessageTypeEventArgs class and using that on multiple events but tossed that out the window as a bad idea just in case I ever needed to extend one event over the others...
Thanks.
|
|
|
|
|
You could always create a generic event args class EventArgs<T> where T is the single data element you want. This does tend to break down a bit when you want multiple data elements, but it's good for a single one without needing to create a bunch of classes that are duplicates of each other except for the property name.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
As the others said, that's the "correct" way.
Along with the benefits already mentioned, is that the custom class can/should implement its own ToString which can add more detail than the string it contains.
I'd give an example, but I won't degrade myself by writing VB. 
|
|
|
|
|
Hi Folks,
While i use Keywords in any code written manually, and Type names in any code generators i use, i have a junior who insists on using the underlying Type name regardless of whether there is a keyword for it or not.
I'd like to stop him doing this, but i don't have the benefits straight in my head. The only reason i can think of is that int would be different on different platforms, but what effect does it have with strings?
Cheers
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: I'd like to stop him doing this
Wanna see how fast he can stop? Fire him for not following company coding standard. 
These aren't neccessarily keywords, but aliases. int (C#) or Integer (VB.NET) is just an alias for System.Int32. I can't remember if they change to 64-bit integers on 64-bit machines or not.
But, with strings, there is no difference at all. string or String is just an alias for System.String. There's no difference at all between using it on 32-bit or 64-bit machines.
|
|
|
|
|
You really have a problem if you are so obsessed with stopping people from doing things their way that you go searching online for excuses.
As you point out yourself, there's no difference, so how about you just let this poor guy (who has to have a boss who spends his time trying to PREVENT him from working the way that works best for him) get on with his work and get the hell out of his way!?
|
|
|
|
|
What ever gave you the impression i was obsessed? I just asked what the mechanical differences were between types and keywords so i could set up a standard on it. I take it you haven't worked anywhere with no code policy and jumbled standards?
I suppose i could be being a bit pedantic asking for proper disposal and that they not use variable names like textBox1, etc.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: not use variable names like textBox1
Well, in my class I teach, I take away points for using variable names like that. Trying to teach people to adopt some kind of decent coding standard.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Dave Kreskowiak wrote: I can't remember if they change to 64-bit integers on 64-bit machines or not.
Nope. Integers are always 32-bits in C#, which I found strange. The C# Language Specification is pretty explicit about it. "The int type represents signed 32-bit integers with values between –2147483648 and 2147483647." Period.
In C/C++, an int was intended to be the "natural" word size of the processor. In Intel x86 processors using DOS, an int was 16 bit. In Win32 and Linux, an int is 32 bits. There were even 24-bit systems where int was defined as 24 bits.
Enjoy,
Robert C. Cartaino
|
|
|
|
|
I remember the C++ types automatically sizing to the proc's width, but I couldn't remember if C#'s int and VB.NET's Integer remapped themselves to System.Int64. I didn't think it did, but I also don't have a 64-bit machine to test with either. 
|
|
|
|
|
Robert.C.Cartaino wrote: In C/C++, an int was intended to be the "natural" word size of the processor.
And I've seen so many cases where developers have written code making assumptions about the size of the data type only to find that their code breaks when they move to 64 bit servers. Standardising on types was part of the remit of the CLR team, so .NET code written for 32 bit would work on 64 bit as well.
|
|
|
|
|
I don't really like the aliases, in my opinion their primary use is to save keystrokes*, but I use them.
One of the odd things about them is that they're required for enumerations:
enum ThisEnum : int ...
enum ThatEnum : System.Int32 ...
And I seem to recall that there are situations where you can't use them, but I could be wrong about that.
* More importantly, they can ease the conversion of C/C++ code to C#, but how many people do that?
|
|
|
|
|
Trying to communicate with a java webservice that utilizes SwA instead of MTOM which is standard in Web Enhancments. Could anyone please tell me how I can do a SwA message in .NET?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
