From: Jackie on
I think it is a too vague what they actually mean here, if that's all
the information you get. Are you sure that's all? Does it mention
something about this "handler" somewhere else?
Says to put that code into a method and invoke the delegate.. Okay,
let's make a method and paste the code in there..
----------------------------------------
private void myMethod()
{
if (MyEvent != null)
MyEvent(this, EventArgs.Empty);

EventArgs e = new EventArgs();

if (handler != null)
{
//invoke the delegete
handler(this != null);
}
}
----------------------------------------

Are you sure this is all their code (in the book)?
"e" is not even used and I don't see where "handler" comes from.
It does not really make sense to me.

I see in your earlier code that it says "handler(this, e);". That makes
more sense but still we don't know where "handler" comes from.

If this is some sort of test and it doesn't say anything about it,
you'll need to make assumptions to show that you tried at least, but
they must mention "handler" somewhere or what you should do a little
more in detail.

If hander == MyEvent, this would work.. But somehow I doubt that is what
they want you to do.
----------------------------------------
private void myMethod()
{
MyEventHandler handler = MyEvent;
if (handler != null)
{
EventArgs e = new EventArgs(); // Move this in here instead
//invoke the delegete
handler(this, e);
}
}
----------------------------------------
From: Jackie on
On 5/30/2010 19:58, Jackie wrote:
> Says to put that code into a method and invoke the delegate.. Okay,
> let's make a method and paste the code in there..

Or rather says to just invoke it from a method but I made a new one
called myMethod because it is easier to see what's going on. You're then
supposed to either call myMethod:
myMethod();
or the code inside from somewhere else (a button's on-click event?).

I think that's all we know from what you said is written in the book,
and can't really know what else to do. That's why I am wondering if
that's all the info you get.
From: Jackie on
Phew... Finally got around getting the total physical memory capacity
via WMI. The code a bit long. I would usually break lines up when they
get long, but I tried not to do it this time because there's a *lot* of
uninteresting code here.
Here it is: http://pastebin.com/u7fCZKd8
It will expire in a month.

I followed the steps in this article (Getting WMI Data from the Local
Computer):
http://msdn.microsoft.com/en-us/library/aa390423(v=VS.85).aspx

I added my previous code to display the information (unfortunately not
your changes) and this is the output:
----------------------------------------
Total physical memory:
4.00: GiB
4.29: GB
----------------------------------------

If that doesn't work, I really have no idea how to solve that problem
with my level of knowledge. I don't like the idea of rounding the number
because I would assume that the value *should* be exact from the beginning.
From: Jackie on
On 5/30/2010 23:17, Jackie wrote:
> Phew... Finally got around getting the total physical memory capacity
> via WMI. The code a bit long. I would usually break lines up when they
> get long, but I tried not to do it this time because there's a *lot* of
> uninteresting code here.
> Here it is: http://pastebin.com/u7fCZKd8
> It will expire in a month.
>
> I followed the steps in this article (Getting WMI Data from the Local
> Computer):
> http://msdn.microsoft.com/en-us/library/aa390423(v=VS.85).aspx
>
> I added my previous code to display the information (unfortunately not
> your changes) and this is the output:
> ----------------------------------------
> Total physical memory:
> 4.00: GiB
> 4.29: GB
> ----------------------------------------
>
> If that doesn't work, I really have no idea how to solve that problem
> with my level of knowledge. I don't like the idea of rounding the number
> because I would assume that the value *should* be exact from the beginning.

Whoops. Wrong thread. Actually, wrong newsgroup as well. Sorry about that.
From: Peter Duniho on
Tony Johansson wrote:
> In the book I read it says the following.
> How to raise an event.
> 1. Create a delegete
> public delegate void MyEventHandler
> 2.Create an event member
> public event MyEventHandler MyEvent
> 3.Invoke the delegete within a method when you need to raise the event, as
> the following code demonstrates
> if (MyEvent != null)
> MyEvent(this, EventArgs.Empty);
>
> EventArgs e = new EventArgs();
>
> if (handler != null)
> {
> //invoke the delegete
> handler(this != null);
> }
>
> I understand everything except the following
> if (handler != null)
> {
> //invoke the delegete
> handler(this != null);
> }
>
> I don't understand what the book wants to says when they already has this
> text
> if (MyEvent != null)
> MyEvent(this, EventArgs.Empty);
>
> Do they want to says that the event can be called handler instead of MyEvent
> ?

As much as I know how awful the book you're using is, I have a feeling
that you may be leaving out some important typographical information in
posting your question, when you quote the book. And I sure hope that
the book isn't actually spelling the word "delegete". :)

In any case, there is no point in raising the event (invoking the
event's delegate field) more than once. So you would never see a method
that raises an event by having _both_:

if (MyEvent != null)
MyEvent(this, EventArgs.Empty);

and�

EventArgs e = new EventArgs();

if (handler != null)
handler(this, e);

Of course, in the second version, "handler" is not even declared.

In general, there are a few things that have to be done when raising an
event:

� Make sure that there's at least one subscriber to the event to
invoke. This is done, for example, by checking for a null delegate
reference.

� Obtain values for all of the arguments that will be passed to the
event handler delegate being invoked. For the standard .NET pattern,
you already have "this" and the remaining parameter will an instance of
some class that inherits EventArgs (including, in the case of
EventHandler or EventHandler<EventArgs>, EventArgs itself).

� Actually invoke the non-null delegate reference representing
subscribers to the event.

For code that does not need to be thread safe, the following is sufficient:

public event EventHandler MyEvent;

void OnMyEvent()
{
if (MyEvent != null)
{
MyEvent(this, EventArgs.Empty);
}
}

Note that there is no point in code that creates a new instance of
EventArgs, as in your second example. The EventArgs class has no data
members to set, so the EventArgs.Empty property always returns an
instance of EventArgs that is suitable for raising any event declared
with EventHandler or EventHandler<EventArgs>.

For code that does need to be thread safe, it is common to see this instead:

void OnMyEvent()
{
EventHandler handler = MyEvent;

if (handler != null)
{
handler(this, EventArgs.Empty);
}
}

The assignment/initialization of "handler" is atomic, so is thread safe.
And once the delegate instance is being referenced by the local
variable, the code is guaranteed the reference won't change between the
time it's compared against "null" and the time it's actually used for
the delegate invocation (as it could in the first example).

Perhaps your book is somehow trying to illustrate this thread-safe
pattern where you are looking.

Finally, either of the above approaches will work for user-defined event
types. It's simply a matter of using the right data for the delegate
invocation arguments. When implementing the standard .NET event
pattern, this may mean passing to the method some data that is then used
to initialize an instance of a class that inherits EventArgs. For other
event signatures, it's the same except that the data is used either
directly as the invocation parameters or is stored in some other data
structure used for the invocation signature.

Pete