Develop Reference

Difference between e.Handeld = true and unsubscribing from event?

I have an event handler that for some reason (I don't understand) get called twice, I thought that setting e.Handled = true will solve it but it doesn't, finally I unsubscribed from the event inside the handler, and it works:
((FabTabItem)sender).TabClosing -= oTab_TabClosing;
So I have these questions:
What is the difference between the both approches, Don't they stop handling the event?
Is it OK to unsubscribe from the event inside its handler since its natural to say "stop listening to the event after it's been handled"? (I don't see this a lot)

From the following MSDN page on the KeyPressEventArgs.Handled Property:
If the event is not handled, it will be sent to the operating system for default processing.
So setting it to true means that any further processing of the event will not happen for the rest of that call to the event depending on how the other events handle the Handled property. As #Enigmativity put it in the comments to the OP:
When you have several handlers for the one event they are called in series. If one of the handlers thinks that it has "handled" the event and no further handlers need to do anything it can set e.Handled = true. It is up to the subsequent handlers to honour this flag and not do any processing - but they are still called. Also this doesn't change the handling for when the next time the event is raised - all of the handlers get called again.
By unsubscribing from the event the rest of the actions in the event still occur, in the case of the above mentioned event it still goes through to the operating system.
The two scenarios you described are not exactly the same.
Unsubscribing from the event inside the handler itself is fine, all it does is remove the call to that handler next time the event is raised.
With that said if you are doing this because the event is being called more times than it should be you should probably track down where the event is being subscribed too. It is likely you have accidentally subscribed the same handler twice and that is the proper fix rather than hacking around it by unsubscribing from the event.

What is the difference between the both approaches, Don't they sop handling the event?
e.Handled = true; indicates that the event handler has already processed the event and dealt with it, so it doesn't need to be processed any further. In other words, please don't take any further action.
but the second will Remove Event and Don,t happen next time
Is it OK to unsubscribe from the event inside its handler since its natural to say "stop listening to the event after it's been handled"? (I don't see this a lot)
its depend to your Roll if you want not happen after a If use handle but if you want never happen after if use second
and remove event

Where should I unregister UWP Application.Current.Suspending event?

I need to perform a set of operation when my application is suspended. I've registered my event as described in Handle app suspending calling registration in page constructor.
public MainPage()
{
Application.Current.Suspending += MainPage_Suspending;
...
}
However I haven't found any reference on how properly unregister this event. Having registered suspending event inside Page constructor unregister it inside the Unload event of page doesn't seem right.
Where should I unregister my suspending event? Should I move registering inside Loaded event and unregister inside Unloaded event instead of using constructor?

If you want to listen to events on static classes in your page instance it is best practice to subscribe in the Page.Loaded event and unsubscribe in the Page.Unloaded event.
Thanks!
Stefan Wick - Windows Developer Platform

wiring and unwiring event

In some cases I have found, developers unwire event then wire it again like this:
control.Click -= new eventHandler(eventHandler)
control.Click += new eventHandler(eventHandler)
why do they do that?

Possibly because there is other code in between that will trigger the event, and they don't want eventHandler to act on it. IMHO this isn't the best way to do things, but it's easy and it works.
If there is no other code in between there cannot possibly be a reason to remove and add the same event handler again.

I can explain this in a simple screnerio.
Imagine you have a "button1"
And you added the event on the run-time.
But once this button is clicked. The process behind it take let say "3Mins" to complete.
And you don't want the user to click this button again.
So you can do by Unwiring it in the first time.
So that the person don't click the button again and again. And adding the instruction in the queue.

If you call code that wires an event, and you don't wont to accidentally wire it up again if it was already wired, you can unwire, and then rewire it. This is the code sample above.
If it wasn't already wired in the first place, no error is thrown. But if the code had already been run first, you don't wont the event to run twice. Thus, unwire and then rewire.

What is this line of code?

Often in code I see a line of code, I have an idea it do something about event but not clearly know what it does.
Is it possible that I can attach form A's load event in Form B with this, or what is its benefit?
this.CGForm .Load +=new EventHandler(CGForm_Load);

Yes, it clearly has to do with events.
.Load in this case the the Form.Load event. The += operator adds one event handler to the event. An event can have many event handlers at the same time. Event handlers are just regular method that can be anywhere in your code base. When the event fires all subscribed methods will be called, one after the other.
I see no particular good reason to have FormA listen to the Load event of FormB, but other events might be more interesting, like the Form.Closed event. This is a way to have FormA react to changes in FormB.
Edit
Note that this causes FormA to hold a reference to FormB and FormB won't be garbage collected until FormA releases the reference to FormB (with
this.CGForm .Load -=new EventHandler(CGForm_Load);, note the -=) this is a common cause for memory leaks in .NET.
Subscribing to events from other forms is a "code smell" that can be a potential structure problem with your code. In some cases it is required, but if you have it all over the place your code will be hard to understand and maintain.

What this line means is that you subscribe the method CGForm_Load() to the this.CGForm.Load event. The method CGForm_Load() is the event handler or the callback.
After you run this line, every time the event is raised (in this case - every time the form is loaded), CGForm_Load() will be called automatically.
In order to unsubscribe a callback, use -= like this:
this.CGForm.Load -= new EventHandler(CGForm_Load)
Once an event callback is unsubscribed, the next time the event is raised (if the form is loaded again) the callback will no longer be called.
I find the following metaphor helpful: An event is like a power outlet, and callbacks are like power plugs. Subscribing is like connecting the plug to the outlet, and unsubscribing is like pulling it out. While there is a connection, all invocations of the event trigger the callback.

It simply adds the GCForm_Load method to the Load event on the CGForm. Under the hood when the CGForm is loaded code like the following will execute. Whenever this happens all event subscribers (in this case the method being subscribed here as CGForm_Load) will be invoked.
<pseudocode>
class CGForm
{
public EventHandler<FormLoadedEventArgs> Load;
private void SomeMethodThatLoadsTheForm()
{
LoadForm();
var loadHandlers = Load;
if (loadHandlers != null)
{
loadHandlers(new FormLoadedEventArgs(...));
}
}
}
</pseudocode>

this.CGForm .Load +=new EventHandler(CGForm_Load); subscribes the event handler delegate CGForm_Load to the Load event of the CGForm object.
Documentation about subscribing to events can be found at http://msdn.microsoft.com/en-us/library/ms366768(v=vs.80).aspx .
And index of information about how events work in .NET can be found at http://msdn.microsoft.com/en-US/library/awbftdfh(v=VS.80).aspx

ListView ItemChecked event

I have a ListView where each item has a checkbox. Initially there are no events attached and I set the state of the checkboxes programatically. After this I attach an ItemCheckedEventHandler and the event handler fires for each of the events that occurred before the handler was attached. Is there a way that I can clear the event queue before attaching the handler?

I was able to re-create when the event was added in the form constructor/InitializeComponent method.
And I was able to get around the problem by adding the event in the form's load event instead of the constructor/InitializeComponent method.

It's hacky, and I don't like it, but Application.DoEvents() might work for you.