raising events by name

[Cor Ligthert[MVP]]

Jon,

As I tried to explain too you, but starting about more things than the wm
message makes it without any need complex, like you showed with your reply.

For instance, you certainly won't get a WM_CLICK message occurring in
the server when a button is clicked in a web page.

By the way, you get normally a XXX_Click back, the handling of that is exact
the same as a WM_CLICK (I did this the last time at thursday so I am
completely sure of that).

As you use C# it is just a double click in the event properties of the
button and then there is exactly the same created as in a windows form
(beside the delegate). In VB it is just setting the handler at the method
to the event from the button in the page.
(Although I assume that the WM click is in web pages not used but a kind of
array, the same as I replied in my first answer to the OP, and by you
repeated somewhere at the end but then instead of an array a dictionary but
that is in my idea just a name)

Cor

 

[Jon Skeet [C# MVP]]

As I tried to explain too you, but starting about more things than the wm
message makes it without any need complex, like you showed with your reply.

You were the one who brought up WM messages and indeed the operating
system in the first place, when there's no need. Why did you even
mention WM style messages?

By the way, you get normally a XXX_Click back, the handling of that is exact
the same as a WM_CLICK (I did this the last time at thursday so I am
completely sure of that).

You get a Click event raised by ASP.NET, but my point is that the
operating system has had very little to do with that.

As you use C# it is just a double click in the event properties of the
button and then there is exactly the same created as in a windows form
(beside the delegate). In VB it is just setting the handler at the method
to the event from the button in the page.

This is irrelevant to the point I was making, which was to counter your
initial claim that: "You are not able to raise up an event, it is
something that comes from the OS."

 

[Cor Ligthert[MVP]]

Cor Ligthert[MVP] <[email protected]> wrote:

You were the one who brought up WM messages and indeed the operating
system in the first place, when there's no need. Why did you even
mention WM style messages?

<snip>

Not for people like you who can not give help without to use everytime 20
messages.

Cor

 

[Dude]

What is the point of reflection if you can't do what you need (raise the
event).

If you are making a game engine and want to expose some classes through
a scripting language and use reflection to make it work, this constraint
will cause hard pain as you will have to implement that dictionnary in
every class you want to expose to the scripting language, which could
easily reach hundreds of classes, not to mention this dictionnary thing
will become a performance issue.

 

[Jon Skeet [C# MVP]]

What is the point of reflection if you can't do what you need (raise the
event).

There are many things that can be done via reflection. Just because it
doesn't happen to solve your immediate problem doesn't make it useless.
Reflection doesn't solve world hunger, either...

If you are making a game engine and want to expose some classes through
a scripting language and use reflection to make it work, this constraint
will cause hard pain as you will have to implement that dictionnary in
every class you want to expose to the scripting language, which could
easily reach hundreds of classes, not to mention this dictionnary thing
will become a performance issue.

Whereas with the approach of adding the Raise part to each event, you'd
have to have the same code repeated for every event. With the
dictionary idea you could even implement a common interface for all of
these classes, so it's clear what's supported.

As for your performance concerns, they seem *incredibly* premature to
me. Dictionary lookups are very cheap - and in the context of
interpreting a scripting language, they're almost guaranteed to pale
into insignificance. Oh, and dictionary lookups are usually cheaper
than using reflection, too

 

[Jon Skeet [C# MVP]]

Well show me how you will get this to compile in c#,
Especially the (RaiseEvent/End RaiseEvent) part.

Public Custom Event MyEvent As EventHandler

AddHandler(ByVal value As EventHandler)
End AddHandler

RemoveHandler(ByVal value As EventHandler)
End RemoveHandler

RaiseEvent(ByVal sender As Object, ByVal e As EventArgs)
End RaiseEvent

End Event

I've just had a closer look at this in MSDN, and it seems that
RaiseEvent is *required* - in other words, you *can't* prevent the
raise part from being present in the metadata. Obviously you can make
it do nothing, but you can't make it absent - whereas in C# you can't
make it present.

Out of interest, does VB have C#'s "field-like" events where you don't
need to provide the implementation yourself at all:

public event EventHandler Click;

for instance?

 

[Jon Skeet [C# MVP]]

Out of interest, does VB have C#'s "field-like" events where you don't
need to provide the implementation yourself at all:

public event EventHandler Click;

for instance?

Isn't it always the way? I found out how to do it immediately after
posting. Ironically, the "quick declaration" form doesn't generate the
raise method... so you can have a custom event declaration which is
*forced* to have one, or a quick event declaration which *won't* have
one.