I just had VS generate an event handler for me, and it created a property instead of a method. I don't understand that. I just tried a separate test in VS 2012, and it worked as expected.
First, this is my test that worked as I thought it would:
private static void EventTest()
{
Geek skeet = new Geek();
skeet.SomeEvent += skeet_SomeEvent;
}
When I had VS generate the handler for me, it created this.
static void skeet_SomeEvent(object sender, EventArgs e)
{
throw new NotImplementedException();
}
That makes sense. That method will be called when the event is invoked.
Now, the problem... I'm working on an existing project, in VS 2010, and when I do the same thing (have VS generate the handler):
private void SubscribeToPlcDataChangeEvents()
{
_plc.PlcLoggerEventHandler += _plcLoggerEventHandler;
}
It creates a property:
public EventHandler<PlcLoggerEventArgs> _plcLoggerEventHandler { get; set; }
Why? I don't get that. I want to handle the event in a method.
EDIT - This is how the event handler is declared:
public event EventHandler<PlcLoggerEventArgs> PlcLoggerEventHandler;
If you hit Tab twice you will notice that it is generated "properly" in cases of event handlers.
In the case where you use the "Options to help bind the item" shortcut Alt+Shift+F10 in Visual Studio 2010, your two possible actions in this case are:
Generate property stub for 'PlcLoggerEventHandler' in ...
Generate field stub for 'PlcLoggerEventHandler' in ...
So, the fact that a property is then created when you use this seems to be By Design, even though in the case of an event handler it makes no sense.
Related
Before to start the question, I would like to inform that I am completely newbie to Xamarin...
I would like to understand what I need implement/add/edit in my solution in my project in order to get
private void canvasView_PaintSurface(object sender, SKPaintSurfaceEventArgs e)
being called by:
public ColorDemo()
{
// some code suppressed here, but not related to the question
SKCanvasView canvasView = new SKCanvasView();
canvasView.PaintSurface += canvasView_PaintSurface;
canvasView.InvalidateSurface();
}
The solution (Visual Studio 2022) runs ok in my smartphone and/or emulator but the event handler is never called. I tried many things, but no success. I would like to understand the reason why the event handler is never called.
I am learning to make a WinForm with c# and I am new to the concept of delegate. After some research on the Internet, it seems that this error arises from inconsistent between the delegate and EventHandler. but they seem fine to me, at least EventArgs definitions are the same. Please tell me what goes wrong.
I've placed this inside the Form1 constructor:
ImageRenamed += OnImageRenamed;
The following code is the custom event I would like to raise when applyBtn_Click is fired.
public delegate void ImageRenamedEventHandler(object sender, EventArgs e);
public event ImageRenamedEventHandler ImageRenamed;
protected virtual void OnImageRenamed()
{
if (ImageRenamed != null)
ImageRenamed(this, EventArgs.Empty);
}
private void applyBtn_Click(object sender, EventArgs e)
{
// do something
OnImageRenamed();
}
You don't need a custom delegate if you're seeking attachment of a method with an (object,EventArgs) signature, just use
public event EventHandler ImageRenamed;
and do away with that delegate definition
Also, you can look at changing the event invoke
protected virtual void OnImageRenamed(EventArgs e)
{
EventHandler eh = ImageRenamed;
eh?.Invoke(this, e);
}
(And call that with EventArgs.Empty)
Caching it into a local variable thus could help prevent potential issues if the handler is removed in the small window of time between using if to determine if it should be invoked and actually invoking it
If the same event will be raised for multiple different images being renamed, consider providing an EventArgs that informs the receiver which image was renamed.
I've placed this inside the Form1 constructor:
Also worth pointing out you seem to have gone wonky here. The OnImageRenamed method invokes the event and is called by the code originating the event. Classes that raise events may do so via a OnXxx method (but they don't have to)
It's not intended to be the method that handles the event. You'd do something more like:
this.ImageRenamed += <press the TAB key twice>
and VS would do something like this for you:
this.ImageRenamed = Form_ImageRenamed;
}
private void Form_ImageRenamed(object sender, EventArgs e){
throw new NotImplementedException();
}
You replace that NIE with the code you want to run when an image is renamed
Also worth noting that you don't really need the form to handle its own event, because it knows it's occurring. It's more typical to have something like an instance of a button (a self contained class) that you use on your form and attach one of your form's methods to its click event; the method that handles the event (in your form) is thus external to the class raising it (Microsoft's button). You could perhaps have another form that has the instance of the form that does the renaming and do e.g.:
renamerForm.ImageRenamed += ...
this way when renaming occurs in foreign form renamerForm a method in the local form is invoked. The sender will be renamerForm
Internally, consider an event to be little more than a list of methods (all with the same signature) that are invoked in any order when the event is raised. You append some method to the list with += and it will be accepted as long as it's signature matches. The following is also valid:
ImageRenamed += (s,e) => MessageBos.Show("The image was renamed");
You have almost done. Your OnImageRenamed needs some parameters:
protected virtual void OnImageRenamed(object sender, EventArgs e)
{
if (ImageRenamed != null)
ImageRenamed(this, EventArgs.Empty);
}
I have a windows form application in which there is a method which dynamically creates controls on a panel but don't know how the method is getting called again and again without being called from a loop this cause controls on panel recreated everytime and panel flicker like nuts
I am unable to find the reason for that any help willbe higly appreciated
Here is the code from which Default controls are loaded
internal void LoadDefaultControl()
{
switch ((ProductType)_tillContext.Till.DefaultProductType)
{
case ProductType.Gift_Voucher:
LoadGiftVouchersControl();
break;
case ProductType.Merchandise:
LoadMerchandiseControl();
break;
case ProductType.Service:
LoadServicesControl();
break;
default:
LoadAdmissionsControl();
break;
}
}
Below method is calling the above method
private void RenewMembership(Domain.Members.Member member, MembershipAdmissionValidityHelper.MembershipAdmissionValidity validity)
{
var wizard =
new PurchaseWizard(control => new MembershipRenewalProcessController(member, validity,
new MembershipRenewalInteractionController(control, _tillContext),
_tillContext))
{
Size = pnlWorkArea.Size
};
wizard.OnCancelled += LoadDefaultControl;
wizard.OnPurchaseCreated += purchase =>
{
AddItemToBasket(purchase);
LoadDefaultControl();
};
ClearControls();
pnlWorkArea.Controls.Add(wizard);
}
Even though you are declaring wizard inside RenewMembership the fact that it has a handler subscribed to the OnCancelled event means that it's never being garbage collected.
Either create the wizard once and once only, adding the event handler then or add the following line to remove the handler:
wizard.OnCancelled -= LoadDefaultControl;
Now this will need to be done after the event fires so is best done in the event handler itself. That means that you need some way of passing the reference to wizard into the handler.
Given that this could get messy very quickly it might be simpler to go with making wizard a private property of the class and only create it once and only add the handler once.
Im aware this may be a slightly odd question, but given a Page class that looks like this:
public class abc:Control
{
public abc()
{
this.Init+=new EventHandler(foo);
this.Load+=new EventHandler(foo);
}
void foo(object sender, eventargs e)
{
//determine whether or not this.Init has already fired.
}
}
I know I could do this by setting a global boolean 'hasinitfired', but I was wondering if this was not necessary or if something as part of the .net library already existed.
Why do you need to know init is fired or not. Init always gets fired during postback or callback. Go through ASP.net page lifecycle, and you will know what all events fired after init and what all before. If you intend to use same handler for different events, yes make a class variable to identify the current event. I recommend attach different handler, and call another method with different param value.
like,
public class abc:Control
{
public abc()
{
this.Init+=new EventHandler(foo1);
this.Load+=new EventHandler(foo2);
}
void foo1(object sender, eventargs e)
{
foo('init');
}
void foo2(object sender, eventargs e)
{
foo('load');
}
void foo(string from)
{
// do something
}
}
This will give cleaner solution and flexibility to add functionality.
I'm guessing you want to know if init has fired when foo runs. As #Adam said, tracing would let you do that if you wanted to see what your app was doing.
Whilst it's running, the best way as I see it would be with a flag, as you suggested.
Simon
This looks like something you'd use the .NET Trace class for. You can use trace to put text in the Visual Studio output window.
Trace.WriteLine("Method called.");
Tracing in .NET has more options than my example:
http://www.15seconds.com/issue/020910.htm
Even further to this, you could use a PostSharp aspect to decorate this method, but that is a third party library.
I am studying events in C# but there are not much articles or information that show me where or what kinda position I'd need to use events in.
Could some one give me real world example that makes them more understandable.
Thanks in advance.
As Chris Gray said, one use is to signal when something has happened that your code didn't directly call. The most common cause here is probably user actions on the GUI. Another example might be an asynchronous operation completing on another thread.
The other reason to use events is when you don't know who might be interested in what has just happened. The class raising the event doesn't need to know (at design time) anything about how many instances of what other classes might be interested.
class Raiser {
public DoSomething() {
//Do something long winded.
OnDidSomething(new DidSomethingEventArgs());
}
public EventHandler<DidSomethingEventArgs> DidSomething;
private OnDidSomething(DidSomethingEventArgs e) {
if (DidSomething != null)
DidSomething(this, e);
}
}
Obviously, you also need to define the DidSomethingEventArgs class which passes on the relevant data about the event. This also illustrates a common naming convention for events. If the event is called X, then the event is only ever raised in a method called OnX and any data it passes on is an instance of class XEventArgs. Note that an event can be null if no listeners are subscribed to it, hence the check just before we raise the event.
Note that this class knows nothing about what other classes might be interested in the fact that it did something. It simply announces the fact that it has done it.
Multiple classes can then listen out for the event:
class ListenerA {
private Raiser r;
ListenerA(Raiser r) {
this.r = r;
r.DidSomething += R_DidSomething;
}
R_DidSomething(object sender, DidSomethingEventArgs e) {
//Do something with the result.
}
}
And:
class ListenerB {
private Raiser r;
ListenerB(Raiser r) {
this.r = r;
r.DidSomething += R_DidSomething;
}
R_DidSomething(object sender, DidSomethingEventArgs e) {
//Do something with the result.
}
}
Now, when the DoSomething method is called on the Raiser instance, all instances of ListenerA and ListenerB will be informed via the DidSomething event. Note that the listener classes could easily be in different assemblies to the raiser. They need a reference back to the raiser's assembly but it doesn't need a reference to its listeners' assemblies.
Note that the above simple Raiser example may cause you some problems in a multi-threaded program. A more robust example would use something like:
class Raiser {
public DoSomething() {
//Do something long winded.
OnDidSomething(new DidSomethingEventArgs());
}
#region DidSomething Event
private object _DidSomethingLock = new object();
private EventHandler<DidSomethingEventArgs> _DidSomething;
public EventHandler<DidSomethingEventArgs> DidSomething {
add { lock(_DidSomethinglock) _DidSomething += value; }
remove { lock(_DidSomethinglock) _DidSomething -= value; }
}
OnDidSomething(DidSomethingEventArgs e) {
EventHandler<DidSomethingEventArgs> handler;
lock (_DidSomethingLock)
handler = _DidSomething;
if (handler == null)
return;
try {
DidSomething(this, e);
} catch (Exception ex) {
//Do something with the exception
}
}
#endregion
}
This ensures that another thread adding or removing a listener while you are in the middle of raising the event doesn't cause problems.
The simple listeners used here will also cause memory leaks if instances of the listener classes are being created and destroyed. This is because the Raiser instance gets passed (and stores) a reference to each listener as they subscribe to the event. This is enough to prevent the garbage collector from properly tidying up the listeners when all explicit references to them are removed. The best way round this is probably to make the listeners implement the IDisposable interface and to unsubscribe from the events in the Dispose method. Then you just need to remember to call the Dispose method.
The most practical example I generally see is User Interactivity. Let's use a Button as a specific example. When the button is clicked, you obviously want something to happen. Let's say we call "SaveSettings()". However, we don't want to hard-code "SaveSettings()" into the button. The buttom would be commanding SaveSettings() to occur. Obviously, this prevents the button from being reusable - we can't use a button which calls SaveSettings() anywhere but the settings dialog. To avoid writing the same button code for every button, each one calling a different function, we use an event.
Instead of the button calling a function directly, the button announces that it has been clicked. From there, the button's responsibility is over. Other code can listen for that announcement, or event, and do something specific.
So in our SaveSettings example, the settings dialog code finds the "OK" button and listens for its "I got clicked" announcement, and when it is fired, calls SaveSettings().
Events can become very powerful because any number of different listeners can wait for the same event. Many things can be invoked by the event.
Sure thing. think of an event as the notification that occurs when something completes in the system that your code didn’t directly call. In C# it's really easy to get code to run when an event "fires"
For example when a user presses a button an event will be raised or when a background network operation completes. In C# you use the += semantics to attach to the event that will be “signaled” when the event fires.
I made you a simple C# winforms program – in it I added a button using the Visual Studio “Designer” (I just dragged a button from the Toolbox to the Window).
You’ll see the line “button1.Click” – in this case I want to do something when the “Click” event is raised.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace events
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
button1.Click += new EventHandler(button1_Click);
}
void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Hi!");
}
}
}
You’ll also see other kinds of events in practice for example:
Network operation has completed (WebClient.DownloadFileCompleted)
User Interfaces (resizing windows for example)
Timers (set off the timer in 10 minutes)
Let's say you are developing a UI. You create a widget and you add it to the main form. When something happens in your widget, you can use events to trigger some action on the form - disabling other buttons, etc.
Just like how a button's click event works.