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****
>>>>
>>>> ** **
>>>>
>>>
>>>
>>
>
