Button1 click oddity? [Resolved]

I have noticed that a button's click handler was assigned like this:

VB Code:

this.button1.Click += new System.EventHandler(this.button1_Click);

What's the deal with += here?

with the += you kind of subscribe to an event!

Hmm... subscribe. Sounds cool. :D

Yes, that's the equivelant to AddHandler in VB.

I see!

"Subscribe", though crptc in nature and not very understandable, sounds cool.

Thanks.

The event handlers already assigned to the click event, PLUS this new handler.

Try the nice feature in C# :
Add this :

this.button1.Click + , then + , then tab . It creates the event handler automatically .

mendhak , it'd be cooler if you check that green mark . It'd looks nice .:afrog:

Quote:

---

Originally posted by mendhak
I see!

"Subscribe", though crptc in nature and not very understandable, sounds cool.

Thanks.

---

"Ascribe" is probably a better word.

In my opinion, the only advantage C# has over VB.net is the ability to override operators. That is what they have done here, they have perverted the self-assignment operator += so that it adds an error handler to an already existing list of error handlers. It is not the conventional usage of the += op.

Note: VB can also assign multiple (consecutive) event handlers to an event.

I guess that depends on how you think about it. What is confusing, at least to me, is when operators do very different things. You have to read the context of how it's used to understand what's going on.

For example, in C#, the "+" operator does one of three things, depending on the context. And I just mean the binary operator, use of the unary + never made sense to me.

For numerics, it calculates the sum, for strings, it concatenates the two strings, and for delegate types, it does delegate concatenation.

I guess it's easy enough to get used to, but I would prefer one operand to add numbers, another to concatenate strings, and another for delegate types.

But that's just me.

Quote:

---

Originally posted by wossname
In my opinion, the only advantage C# has over VB.net is the ability to override operators. That is what they have done here, they have perverted the self-assignment operator += so that it adds an error handler to an already existing list of error handlers. It is not the conventional usage of the += op.

---

My quest of learning VB had made me overlook that part.

One peeve of mine is that C# gets the /// summary and VB.NET doesn't. Imagine the multitude of Sandpaper.NET users out there who need to constantly refer to the documentation. :D

Quote:

---

Originally posted by Mike Hildner
the unary + never made sense to me.

---

I've seen it used as a shortcut for Math.Abs(). Forces any value to positive.

Bad code practice if you ask me though.

Mend, I agree about the ///<summary> thingy. What I am planning to do though, is use the "Build Comment Pages" utility in the IDE. The output isn't very stylish but it takes a huge amount of the donkeywork out of writing the documentation.

Quote:

---

I've seen it used as a shortcut for Math.Abs(). Forces any value to positive.

---

I didn't know that. Gave it a try, but I guess I'm doing something wrong? This code

Code:

---

                        int i = -42;
                        i = + i;
                        System.Diagnostics.Debug.WriteLine(i.ToString());

---

prints out - 42.

Quote:

---

Originally Posted by wossname

"Ascribe" is probably a better word.

In my opinion, the only advantage C# has over VB.net is the ability to override operators. That is what they have done here, they have perverted the self-assignment operator += so that it adds an error handler to an already existing list of error handlers. It is not the conventional usage of the += op.

Note: VB can also assign multiple (consecutive) event handlers to an event.

---

and pointers?

Getting off topic. += makes perfect sense for delegates, which I guess was part of the original author's question.

Quote:

---

and pointers?

---

Without getting into a language war, I agree. Please correct me if I'm wrong, but I believe that C# can do everything that VB.NET can do, plus some. VB.NET cannot claim the same thing. There's nothing unique to VB.NET that can't be done in C#.

Coming from a classic VB background, naturaly I started with VB.NET. From there, it's easy to get exposed to C#, which now I prefer, for the above stated reasoning.

That, and the emotional security that comes with a semicolon at the end of every line :)

VB 2005 will have everything that C# does. Correct?

mendhak, not sure if you were directing that question at me or not. Answering just in case. I have no idea what tomorrow may bring. Seems like you hear things that VB will "catch up" to some features that C# has, I can only hope that C# IntelliSense gets as good as VB.

Quote:

---

Originally Posted by mendhak

VB 2005 will have everything that C# does. Correct?

---

Actually VB 2005 will have some features that C# doesnt. For example the Me class. This includes some features such as checking network connection, getting the name of the current machine,..... that got more complicated from vb6 to vb .net. They bring back that easy access to key features like that in vb.net 2005.

Quote:

---

Originally Posted by Sgt-Peppa

Actually VB 2005 will have some features that C# doesnt. For example the Me class. This includes some features such as checking network connection, getting the name of the current machine,..... that got more complicated from vb6 to vb .net. They bring back that easy access to key features like that in vb.net 2005.

---

You mean the My keyword. I just read about that a couple days ago. Good stuff.

Quote:

---

Originally Posted by mendhak

You mean the My keyword. I just read about that a couple days ago. Good stuff.

---

Yup, its called
MY

My bad :blush:, sorry

Stephan

Quote:

---

Originally Posted by Sgt-Peppa

My.bad :blush:

---

:lol: :lol: :afrog: