This is why I write bugs. So that my powers may never be used for evil.
On Mon, Apr 2, 2012 at 11:21 AM, Stephen Price <step...@perthprojects.com>wrote:
> Now for some reason, my reply has conjured up images of an evil overlord
> with his hand on Micheals brain, sucking out all of his powers...
>
> Hmm... time for another coffee.
>
>
> On Mon, Apr 2, 2012 at 11:19 AM, Stephen Price
> <step...@perthprojects.com>wrote:
>
>> Your mind is indeed a sponge. Squeeze it and you get all kinds of goodies
>> come out. :)
>>
>>
>> On Mon, Apr 2, 2012 at 11:16 AM, Michael Minutillo <
>> michael.minuti...@gmail.com> wrote:
>>
>>> You're welcome :)
>>>
>>> I often end up with a container class of some description too (like the
>>> following) which makes aggregating these sorts of things very easy. By the
>>> end of the previous project just about every view in our system had a
>>> container and disposed of it when it was destroyed. So much so that we
>>> pushed it into a base class and it became the common pattern for handling
>>> things like bindings, event subscriptions, micro-controllers, etc.
>>>
>>> class Container : IDisposable
>>> {
>>> private readonly IList<object> _objects = new List<object>();
>>>
>>> public void Add(object o)
>>> {
>>> _objects.Add(o);
>>> }
>>>
>>> public void Flush()
>>> {
>>> foreach(var obj in _objects.OfType<IDisposable>().Reverse())
>>> obj.Dispose();
>>> _objects.Clear()
>>> }
>>>
>>> public void Dispose()
>>> {
>>> Flush();
>>>
>>> }
>>> }
>>>
>>> On Mon, Apr 2, 2012 at 10:59 AM, Stephen Price <
>>> step...@perthprojects.com> wrote:
>>>
>>>> So looking at Michael's example, the viewmodel would register the
>>>> object and then in its Dispose method, call the Dispose on the object it
>>>> got back (and kept track of).
>>>>
>>>> understand it, and will file this one away for when I need it. I think
>>>> i'm ok with what I have because the actual class is not static, only the
>>>> Registration and unreg (+ and - operations) are static.
>>>>
>>>> I should have looked before I leapt(posted to list) but had I not, I
>>>> wouldn't have gotten this gem from the sponge that is Michael's mind. So
>>>> glad I did. :)
>>>>
>>>> Thanks!
>>>>
>>>> On Mon, Apr 2, 2012 at 10:37 AM, James Chapman-Smith <
>>>> ja...@chapman-smith.com> wrote:
>>>>
>>>>> Hi Michael,****
>>>>>
>>>>> ** **
>>>>>
>>>>> This is an awesome pattern for solving this problem. I use it myself
>>>>> quite a lot. I think it is perfect for Stephen.****
>>>>>
>>>>> ** **
>>>>>
>>>>> Cheers.****
>>>>>
>>>>> ** **
>>>>>
>>>>> James.****
>>>>>
>>>>> ** **
>>>>>
>>>>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
>>>>> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Michael Minutillo
>>>>> *Sent:* Monday, 2 April 2012 11:11
>>>>> *To:* ozDotNet
>>>>> *Subject:* Re: Unhooking events from Handler****
>>>>>
>>>>> ** **
>>>>>
>>>>> In the past I have done something like this:
>>>>>
>>>>> class Disposable : IDisposable
>>>>> {
>>>>> private readonly Action _action;
>>>>> public Disposable(Action action)
>>>>> {
>>>>> _action = action;
>>>>> }
>>>>>
>>>>> public void Dispose()
>>>>> {
>>>>> _action();
>>>>> }
>>>>> }
>>>>>
>>>>> public interface IHandle<TMessage>
>>>>> {
>>>>> void Handle(TMessage message);
>>>>> }
>>>>>
>>>>> public static class Events
>>>>> {
>>>>> private static readonly IList<object> _handlers = new
>>>>> List<object>();
>>>>>
>>>>> public static IDisposable Register(object o)
>>>>> {
>>>>> _handlers.Add(o);
>>>>> return new Disposable(() => _handlers.Remove(o));
>>>>> }
>>>>>
>>>>> public static void Raise<TMessage>(TMessage message)
>>>>> {
>>>>> foreach(var handler in _handlers.OfType<IHandle<TMessage>>())
>>>>> handler.Handle(message);
>>>>> }
>>>>> }
>>>>>
>>>>> That way the registration code returns some kind of "subscription
>>>>> token". Whoever adds the handler is responsible for disposing of the token
>>>>> and therefore cancelling the subscription. There's lots you can do around
>>>>> background threads, error handling, locking (for thread safety) etc. but
>>>>> the above is the basic skeleton I end up using.
>>>>>
>>>>> Michael M. Minutillo
>>>>> Indiscriminate Information Sponge
>>>>> http://codermike.com
>>>>>
>>>>> ****
>>>>>
>>>>> On Mon, Apr 2, 2012 at 9:27 AM, David Walker <rangitat...@gmail.com>
>>>>> wrote:****
>>>>>
>>>>> http://msdn.microsoft.com/en-us/library/ee658248.aspx search on the
>>>>> page for 'static event' should find the best ways to do this.
>>>>>
>>>>> Typically the child will unsubscribe itself inside Dispose()****
>>>>>
>>>>>
>>>>> On 2 Apr 2012, at 02:21, Stephen Price wrote:
>>>>>
>>>>> > Hey all,
>>>>> >
>>>>> > I've got a Static class that's behaving like an EventHandler in that
>>>>> you assign values to it via an operator + or - method.
>>>>> >
>>>>> > I need a method on this thing or some way that I can unhook the ones
>>>>> from one particular class (called from the dispose of that class) so that
>>>>> it can remove only the ones that were added from that class. Its accepting
>>>>> an Enum, so is there a way to see the owner of an Enum or where it was
>>>>> created?
>>>>> >
>>>>> > Or do I need to store something along with the Enum that can later
>>>>> be used to identify who attached it?
>>>>> >
>>>>> > If you imagine it as a Static eventhandler, how can I look through
>>>>> the references and only unhook the ones from a particular class. (assuming
>>>>> internally you can loop through each handler.
>>>>> > The actual problem is that it's causing a memory leak if I don't
>>>>> unhook these things when that page/veiwmodel is disposed.
>>>>> >
>>>>> > hope the above makes some kind of sense to someone. :)
>>>>> >
>>>>> > cheers,
>>>>> > Stephen****
>>>>>
>>>>> ** **
>>>>>
>>>>
>>>>
>>>
>>
>
