In my .NET application I am subscribing to events from another class. The subscription is conditional. I am subscribing to events when the control is visible and de-subscribing it when it become invisible. However, in some conditions I do not want to de-subscribe the event even if the control is not visible as I want the result of an operation which is happening on a background thread.
Is there a way through which I can determine if a class has already subscribed to that event?
I know we can do it in the class which will raise that event by checking the event for null, but how do I do it in a class which will subscribe to that event?
The event keyword was explicitly invented to prevent you from doing what you want to do. It restricts access to the underlying delegate object so nobody can directly mess with the events handler subscriptions that it stores. Events are accessors for a delegate, just like a property is an accessor for a field. A property only permits get and set, an event only permits add and remove.
This keeps your code safe, other code can only remove an event handler if it knows the event handler method and the target object. The C# language puts an extra layer of security in place by not allowing you to name the target object.
And WinForms puts an extra layer of security in place so it becomes difficult even if you use Reflection. It stores delegate instances in an EventHandlerList with a secret "cookie" as the key, you'd have to know the cookie to dig the object out of the list.
Well, don't go there. It is trivial to solve your problem with a bit of code on your end:
private bool mSubscribed;
private void Subscribe(bool enabled)
{
if (!enabled) textBox1.VisibleChanged -= textBox1_VisibleChanged;
else if (!mSubscribed) textBox1.VisibleChanged += textBox1_VisibleChanged;
mSubscribed = enabled;
}
Assuming that you have no access to the innards of the class declaring the event, you have no way to do it directly. Events only expose operators += and -=, nothing else. You will need a flag or some other mechanism in your subscribing class to know whether you are already subscribed or not.
/// <summary>
/// Determine if a control has the event visible subscribed to
/// </summary>
/// <param name="controlObject">The control to look for the VisibleChanged event</param>
/// <returns>True if the control is subscribed to a VisibleChanged event, False otherwise</returns>
private bool IsSubscribed(Control controlObject)
{
FieldInfo event_visible_field_info = typeof(Control).GetField("EventVisible",
BindingFlags.Static | BindingFlags.NonPublic);
object object_value = event_visible_field_info.GetValue(controlObject);
PropertyInfo events_property_info = controlObject.GetType().GetProperty("Events",
BindingFlags.NonPublic | BindingFlags.Instance);
EventHandlerList event_list = (EventHandlerList)events_property_info.GetValue(controlObject, null);
return (event_list[object_value] != null);
}
Simply check whether the control is visible or not whenever the event handler is triggered.
Can you put the decision making logic into the method that fires the event? Assuming you're using Winforms it'd look something like this:
if (MyEvent != null && isCriteriaFulfilled)
{
MyEvent();
}
Where isCriteriaFulfilled is determined by your visible/invisible logic.
// UPDATES /////
Further to your 1st comment would it not make sense to alter the behaviour inside your event handler depending on the value of this.Visible?
a.Delegate += new Delegate(method1);
...
private void method1()
{
if (this.Visible)
// Do Stuff
}
Or if you really have to go with subscribing and unsubscribing:
private Delegate _method1 = null;
...
if(this.visible)
{
if (_method1 == null)
_method1 = new Delegate(method1);
a.Delegate += _method1;
}
else if (_method1 != null)
{
a.Delegate -= _method1;
}
using System;
//...
public event EventHandler Event;
public bool IsSubscribed(EventHandler Delegate)
{
if (Event == null)
{
return false;
}
var InvocationList = Event.GetInvocationList();
foreach (var Entry in InvocationList)
{
if (Entry.Equals(Delegate))
{
return true;
}
}
return false;
}
After 12 years it is here, works for me.
Can't you just remember whether you already subscribed? That approach worked fine for me so far. Even if you have a lot of events or objects, you may still want to just remember that (in a dictionary, for example).
On the other hand, visibility change was, at least for me, not a good point to subscribe/unsubscribe. I typically rather go with construction / Disposed, which are more clear than each time visibility changes.
I'm just expanding on Hans' answer. I'm just trying to ensure that I'm not installing my handler more than once, and not removing it when I still need it. This doesn't protect from a malicious or malfeasant caller unsubscribing repeatedly, for that you'd need to track the callers, and that would just open you up to having repeated subscriptions overrun the tracking mechanism.
// Tracks how many times the ReflectionOnlyResolveHandler has been requested.
private static int _subscribers = 0;
/// <summary>
/// Register or unregister the ReflectionOnlyResolveHandler.
/// </summary>
/// <param name="enable"></param>
public static void SubscribeReflectionOnlyResolve(bool enable)
{
lock(_lock)
{
if (_subscribers > 0 && !enable) _subscribers -= 1;
else if (enable) _subscribers += 1;
if (enable && _subscribers == 1)
AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve += ReflectionHelper.ReflectionOnlyResolveHandler;
else if (_subscribers == 0)
AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve -= ReflectionHelper.ReflectionOnlyResolveHandler;
}
}
Related
I have a ton on controls on a form, and there is a specific time when I want to stop all of my events from being handled for the time being. Usually I just do something like this if I don't want certain events handled:
private bool myOpRunning = false;
private void OpFunction()
{
myOpRunning = true;
// do stuff
myOpRunning = false;
}
private void someHandler(object sender, EventArgs e)
{
if (myOpRunning) return;
// otherwise, do things
}
But I have A LOT of handlers I need to update. Just curious if .NET has a quicker way than having to update each handler method.
You will have to create your own mechanism to do this. It's not too bad though. Consider adding another layer of abstraction. For example, a simple class called FilteredEventHandler that checks the state of myOpRunning and either calls the real event handler, or suppresses the event. The class would look something like this:
public sealed class FilteredEventHandler
{
private readonly Func<bool> supressEvent;
private readonly EventHandler realEvent;
public FilteredEventHandler(Func<bool> supressEvent, EventHandler eventToRaise)
{
this.supressEvent = supressEvent;
this.realEvent = eventToRaise;
}
//Checks the "supress" flag and either call the real event handler, or skip it
public void FakeEventHandler(object sender, EventArgs e)
{
if (!this.supressEvent())
{
this.realEvent(sender, e);
}
}
}
Then when you hook up the event, do this:
this.Control.WhateverEvent += new FilteredEventHandler(() => myOpRunning, RealEventHandler).FakeEventHandler;
When WhateverEvent gets raised, it will call the FilteredEventHandler.FakeEventHandler method. That method will check the flag and either call, or not call the real event handler. This is pretty much logically the same as what you're already doing, but the code that checks the myOpRunning flag is in only one place instead of sprinkled all over your code.
Edit to answer question in the comments:
Now, this example is a bit incomplete. It's a little difficult to unsubscribe from the event completely because you lose the reference to the FilteredEventHandler that's hooked up. For example, you can't do:
this.Control.WhateverEvent += new FilteredEventHandler(() => myOpRunning, RealEventHandler).FakeEventHandler;
//Some other stuff. . .
this.Control.WhateverEvent -= new FilteredEventHandler(() => myOpRunning, RealEventHandler).FakeEventHandler; //Not gonna work!
because you're hooking up one delegate and unhooking a completely different one! Granted, both delegates are the FakeEventHandler method, but that's an instance method and they belong to two completely different FilteredEventHandler objects.
Somehow, you need to get a reference to the first FilteredEventHandler that you constructed in order to unhook. Something like this would work, but it involves keeping track of a bunch of FilteredEventHandler objects which is probably no better than the original problem you're trying to solve:
FilteredEventHandler filter1 = new FilteredEventHandler(() => myOpRunning, RealEventHandler);
this.Control.WhateverEvent += filter1.FakeEventHandler;
//Code that does other stuff. . .
this.Control.WhateverEvent -= filter1.FakeEventHandler;
What I would do, in this case, is to have the FilteredEventHandler.FakeEventHandler method pass its 'this' reference to the RealEventHandler. This involves changing the signature of the RealEventHandler to either take another parameter:
public void RealEventHandler(object sender, EventArgs e, FilteredEventHandler filter);
or changing it to take an EventArgs subclass that you create that holds a reference to the FilteredEventHandler. This is the better way to do it
public void RealEventHandler(object sender, FilteredEventArgs e);
//Also change the signature of the FilteredEventHandler constructor:
public FilteredEventHandler(Func<bool> supressEvent, EventHandler<FilteredEventArgs> eventToRaise)
{
//. . .
}
//Finally, change the FakeEventHandler method to call the real event and pass a reference to itself
this.realEvent(sender, new FilteredEventArgs(e, this)); //Pass the original event args + a reference to this specific FilteredEventHandler
Now the RealEventHandler that gets called can unsubscribe itself because it has a reference to the correct FilteredEventHandler object that got passed in to its parameters.
My final advice, though is to not do any of this! Neolisk nailed it in the comments. Doing something complicated like this is a sign that there's a problem with the design. It will be difficult for anybody who needs to maintain this code in the future (even you, suprisingly!) to figure out the non-standard plumbing involved.
Usually when you're subscribing to events, you do it once and forget it - especially in a GUI program.
You can do it with reflection ...
public static void UnregisterAllEvents(object objectWithEvents)
{
Type theType = objectWithEvents.GetType();
//Even though the events are public, the FieldInfo associated with them is private
foreach (System.Reflection.FieldInfo field in theType.GetFields(System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance))
{
//eventInfo will be null if this is a normal field and not an event.
System.Reflection.EventInfo eventInfo = theType.GetEvent(field.Name);
if (eventInfo != null)
{
MulticastDelegate multicastDelegate = field.GetValue(objectWithEvents) as MulticastDelegate;
if (multicastDelegate != null)
{
foreach (Delegate _delegate in multicastDelegate.GetInvocationList())
{
eventInfo.RemoveEventHandler(objectWithEvents, _delegate);
}
}
}
}
}
You could just disable the container where all these controls are put in. For example, if you put them in a GroupBox or Panel simply use: groupbox.Enabled = false; or panel.Enabled = false;. You could also disable the form From1.Enabled = false; and show a wait cursor. You can still copy and paste these controls in a container other than the form.
My code is as follows.
Control[] FoundControls = null;
FoundControls = MyFunctionToFilter(TF, c => c.Name != null && c.Name.StartsWith("grid"));
var eventinfo = FoundControls[0].GetType().GetEvents();
However, eventinfo gives me the list of all the controls which belongs to the grid.
Whereas there are only two events that are defined that is KeyDown and Validating in the main class.
How can I get a list of these assigned events, that is, Keydown and Validating?
Windows Forms (WinForms) has a tricky model of events for components (and DataGridView is a component). Some events are inherited from Control (like FontChanged, ForeColorChanged, etc.), but all specific to component events are stored in a single EventHandlerList object, which is inherited from Component (BTW, events from Control are also stored there, see the update at the end of the answer). There is a protected Events property for that:
protected EventHandlerList Events
{
get
{
if (this.events == null)
this.events = new EventHandlerList(this);
return this.events;
}
}
And here is the way how event handlers are added for DataGridView events:
public event DataGridViewCellEventHandler CellValueChanged
{
add { Events.AddHandler(EVENT_DATAGRIDVIEWCELLVALUECHANGED, value); }
remove { Events.RemoveHandler(EVENT_DATAGRIDVIEWCELLVALUECHANGED, value); }
}
As you can see, delegate (value) is passed to EventHandlerList with some key value. All event handlers are stored there by key. You can think about EventHandlerList as a dictionary with objects as keys, and delegates as values. So, here is how you can get components' events with reflection. The first step is getting those keys. As you already noticed, they are named as EVENT_XXX:
private static readonly object EVENT_DATAGRIDVIEWCELLVALUECHANGED;
private static readonly object EVENT_DATAGRIDVIEWCELLMOUSEUP;
// etc.
So here we go:
var keys = typeof(DataGridView) // You can use `GetType()` of component object.
.GetFields(BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.FlattenHierarchy)
.Where(f => f.Name.StartsWith("EVENT_"));
Next, we need our EventHandlerList:
var events = typeof(DataGridView) // or GetType()
.GetProperty("Events", BindingFlags.Instance | BindingFlags.NonPublic);
// Could be null, check that
EventHandlerList handlers = events.GetValue(grid) as EventHandlerList;
And the last step, getting the list of keys, which have handlers attached:
var result = keys.Where(f => handlers[f.GetValue(null)] != null)
.ToList();
That will give you the keys. If you need delegates, then simply look in the handlers list for them.
UPDATE: Events which inherited from Control are also stored in EventHandlerList, but for some unknown reason their keys have different names, like EventForeColor. You can use the same approach as above to get those keys and check if handlers are attached.
According to the comments in this question showing that this is a Windows Forms related question it's almost not possible to determine assigned event handlers by iterating the list, not without reflection anyway.
The following text is from Hans Passant's answer on a similar question:
Windows Forms has strong counter-measures against doing this. Most
controls store the event handler reference in a list that requires a
secret 'cookie'. The cookie value is dynamically created, you cannot
guess it up front. Reflection is a backdoor, you have to know the
cookie variable name. The one for the Control.Click event is named
"EventClick" for example, you can see this in the Reference Source or
with Reflector.
Knowing the cookie name would help you get the assigned event, but I am not sure if there is such a list with all the names which you could iterate. See this other answer which demonstrates how to get an event from one control where the cookie name is known.
Here you can find another example (which still goes by using a known event name).
Can't you use reflection to look the list of handlers?
Here is a simple console app looking at handlers hooked on the events of a serial port instance:
using System;
using System.IO.Ports;
using System.Reflection;
class Program
{
static void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e){}
static void Main(string[] args)
{
var serialPort = new SerialPort();
// Add a handler so we actually get something out.
serialPort.ErrorReceived += OnErrorReceived;
foreach (var eventInfo in serialPort.GetType().GetEvents())
{
var field = serialPort.GetType().GetField(eventInfo.Name, BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField);
if (field != null)
{
var backingDelegate = (Delegate)field.GetValue(serialPort);
if (backingDelegate != null)
{
var subscribedDelegates = backingDelegate.GetInvocationList();
foreach (var subscribedDelegate in subscribedDelegates)
{
Console.WriteLine(subscribedDelegate.Method.Name + " is hooked on " + eventInfo.Name);
}
}
}
}
}
}
Based on Kyle comment:
#Jacob Yes.... Because these are the only two events declared in the
main class – Kyle
Events would contain KeyDown and Validating events only.
Control a = new TextBox();
var events = a.GetType().GetEvents().Where(eventInfo => eventInfo != null && (eventInfo.Name == "KeyDown" || eventInfo.Name == "Validating"));
+events.ToList()[0] {System.Windows.Forms.KeyEventHandler KeyDown}
+events.ToList()[1] {System.ComponentModel.CancelEventHandler Validating}
I'm creating custom control that contain multiple parts. Inside template creation I'm subscribing for different events like so:
public override void OnApplyTemplate()
{
base.OnApplyTemplate();
this.partAreaCode = this.GetTemplateChild(PartAreaCode) as TextBox;
this.partExchange = this.GetTemplateChild(PartExchange) as TextBox;
this.partSubscriber = this.GetTemplateChild(PartSubscriber) as TextBox;
if (this.partAreaCode == null || this.partExchange == null || this.partSubscriber == null)
{
throw new NullReferenceException("Template part(s) not available");
}
this.partAreaCode.KeyDown += this.AreaKeyDown;
this.partAreaCode.TextChanged += this.AreaTextChanged;
this.partExchange.KeyDown += this.ExchangeKeyDown;
this.partExchange.TextChanged += this.ExchangeTextChanged;
this.partSubscriber.KeyDown += this.SubscriberKeyDown;
// Template might be applied after dependency property set
// lets refresh UI in this case
this.UIFromValue();
}
So, I wonder if I should unsubscribe from those events and if so - where and how?
You don't have to. Because your PART elements are children of the event subscriber. If your main control gets garbage collected, so do your PART elements.
A short example. Lets say you have 2 instances A and B ... A keeps a hard reference to B. If B is only hold in memory by the reference in A and A gets garbage collected so does B. You don't need to clear the reference in A first.
If for some reason you don't want events anymore while your element, with your PART child elements, lives you have to unsubsribe of course.
A Rule of thumb: Always unsubscribe events if the event owner lives longer than the subscriber.
Well you've accepted an answer already and you may be able to get away that approach but its a too risky for my tastes. It assumes that OnApplyTemplate only ever gets called once. Potentially though your custom control may live a long time with OnApplyTemplate getting called more than once.
I'll outline here what hard-core control developers do, I'll just use one TextBox for brevity.
[TemplatePart(Name = MyControl.PartAreaCode, Type = typeof(TextBox))]
public partial class MyControl: Control
{
public MyControl()
{
DefaultStyleKey = typeof(MyControl);
}
#region Template Part Names
private const string PartAreaCode = "AreaCodeTextBox";
#endregion
#region internal TextBox AreaCodeTextBox
private TextBox _AreaCodeTextBox;
internal TextBox AreaCodeTextBox
{
get { return _AreaCodeTextBox; }
set
{
if (_AreaCodeTextBox != null)
{
_AreaCodeTextBox -= AreaCodeTextBox_KeyDown;
_AreaCodeTextBox -= AreaCodeTextBox_TextChanged;
}
_AreaCodeTextBox = value;
if (_AreaCodeTextBox != null)
{
_AreaCodeTextBox += AreaCodeTextBox_KeyDown;
_AreaCodeTextBox += AreaCodeTextBox_TextChanged;
}
}
}
#endregion
public overide void OnApplyTemplate()
{
base.OnApplyTemplate();
AreaCodeTextBox = GetTemplateChild(PartAreaCode) as TextBox;
}
#region Part Event Handlers
// Your event handlers here
#endregion
}
Yes I know that this looks like overkill but the code is boilerplate and we use regions to rollup the repeative stuff so we can inspect code that actually does something interesting without being concerned with the plumbing. With this one instance its easy to roll it out to multiple parts.
I have event handlers for intercepting call logs on windows mobile. The problem is more specific to event handlers in C# rather than windows mobile. I am able to attach and detach event handlers for the first time. The proble is: I am not able to attach event handler after its detached at least once. Why are the event handlers not invoked after its detached and again attached?
Below is my code:
private static SystemState stateIncoming = null;
private static SystemState stateOutgoing = null;
private static SystemState stateTalking = null;
public static void StartCallLogInterception()
{
if (stateIncoming == null && stateOutgoing == null && stateTalking == null)
{
stateIncoming = new SystemState(SystemProperty.PhoneIncomingCall);
stateIncoming.Changed += new ChangeEventHandler(stateIncoming_Changed);
stateOutgoing = new SystemState(SystemProperty.PhoneCallCalling);
stateOutgoing.Changed += new ChangeEventHandler(stateOutgoing_Changed);
stateTalking = new SystemState(SystemProperty.PhoneCallTalking);
stateTalking.Changed += new ChangeEventHandler(stateTalking_Changed);
}
}
public static void EndCallLogInterception()
{
if (stateIncoming != null && stateOutgoing != null && stateTalking != null)
{
stateIncoming.Changed -= new ChangeEventHandler(stateIncoming_Changed);
stateIncoming = null;
stateOutgoing.Changed -= new ChangeEventHandler(stateOutgoing_Changed);
stateOutgoing = null;
stateTalking.Changed -= new ChangeEventHandler(stateTalking_Changed);
stateTalking = null;
}
}
EDIT: I updated code to include class level variable. Also, below answers conflict with each other. If I am disposing object, I must re-create the object when I need to attach event handler. Does this make sense?
EDIT 2: The problem is not with objects or event handling code. I am using LargeIntervalTimer from OpenNETCF. Whenever I am running timer using LargeIntervalTimer, the event handler is not attached properly. Without LargeIntervalTimer, everything is working fine.
Well, it's not really clear from just the code you've given, but I wonder whether it's because you're never disposing of the SystemState objects you're creating. If you change your code to dispose of them properly when you unsubscribe, that may help.
Alternatively, don't bother keeping on creating new objects - just create the three objects up-front, and then subscribe/unsubscribe as appropriate.
You don't need the
stateTalking.Changed -= new ChangeEventHandler(stateTalking_Changed);
code. First, you are not removing the same thing you put in, you are removing a new instance og the ChangeVenetHandler. Second, all event handlers are removed when you run
stateTalking = null;
because of the Garage Collection.
As Jon Skeet said, you never run the code
stateTalking.Dispose();
before you remove it.
Check your if statements. Place a break point and make sure that you even enter the condition that wires-up the handlers. I suspect that you are not reaching the code in subsequent calls, likely because one of the objects is not null.
I'm using events as part of a game model, and for extensibility and code "locality's" sake I need to be able to veto most actions.
More clearly, nearly every method that has a side effect takes this form:
public event TryingToDoSomethingHandler TryingToDoSomething;
public event SomethingHappenedHandler SomethingHappened;
/*
* Returning true indicates Something happened successfully.
*/
public bool DoSomething(...)
{
//Need a way to indicate "veto" here
TryingToDoSomething(...);
//Actual do it
SomethingHappened(...);
return true;
}
What I'd like is for TryingToDoSomething(...) to be able to indicate that a registered event handler objects (via returning false, modifying an out parameter, or something). So that the code is morally equivalent to:
/*
* Returning true indicates Something happened successfully.
*/
public bool DoSomethingImproved(...)
{
//Pretty sure multicast delegates don't work this way, but you get the idea
if(!TryingToDoSomething(...)) return false;
//Actual do it
SomethingHappened(...);
return true;
}
Is there an accepted or standard way to do this in C#/.NET?
Are you thinking about Cancelable events? The framework uses that extensively.
Create a EventArgs class that has a Cancel property that implements get/set. The event handler can then set the Cancel property to true, which you can check when the call returns.
public bool TrySomething()
{
CancelEventArgs e = new CancelEventArgs();
if (Event1 != null) Event1.Invoke(e);
if (e.Cancel == false)
{
if (Event2 != null) Event2.Invoke(e);
}
}
Take a look at the CancelEventHandler and CancelEventArgs classes. They follow a pattern where each event handler can cancel the event.