From: Jackie on 30 May 2010 13:58 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 30 May 2010 14:02 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 30 May 2010 17:17 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 30 May 2010 17:19 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 30 May 2010 19:02 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Transparent form with hourglass? Next: SQLSiteMapProvider with a parameter problem |