raising events by name

  • Thread starter Thread starter buu
  • Start date Start date
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.
Click to expand...

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
 
Cor Ligthert said:
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.
Click to expand...

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).
Click to expand...

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.
Click to expand...

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."
 
Jon Skeet said:
Cor Ligthert[MVP] <[email protected]> wrote:
Click to expand...

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?
Click to expand...
<snip>

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

Cor
 
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.
 
Dude said:
What is the point of reflection if you can't do what you need (raise the
event).
Click to expand...

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.
Click to expand...

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 :)
 
Dude said:
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
Click to expand...

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?
 
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?
Click to expand...

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.
 
Back
Top