asked on

Removed element still listens to events

Hello there

I got a canvas on what I add some UIElements like this:

private void AddChild(UIElement child, Canvas parent)
{
    // first I remove all the other children
    parent.Children.Clear();

    // then I add the new one
    parent.Children.Add(child);
}

Open in new window

I add my new field on this canvas like this:

private void AddField()
{
    AddChild(new FieldView(), MainCanvas);
}

Open in new window

So I have no other reference to that FieldView, but on the canvas.

This FieldView listens to some events and shows some MessageBoxes. Now, when I add a new FieldView on the MainCanvas, the only reference of the old one should be removed (if I understand this parent.Children.Clear() right).

But it seems like it's not really collected by the GarbageCollector, because now, I always get 2 MessageBoxes on these events (if I add a new field again, I get 3 MessageBoxes and so on).

Can anyone of you tell me, why the old FieldViews aren't removed? Is it just because they still listen to those events or doesn't parent.Children.Clear() really remove them?

Thank you for your help!

jagrut_patel

Is the event that FieldView listens to static?

smickle

If you are wiring up the event handler in code, you may have to "unwire" the event handler first. Example:

var someElement = whatever;

// unwire event handler if there is one
someElement.SomeEvent -= this.someEventHandler;

// wire event handler
someElement.SomeEvent += this.someEventHandler;

Open in new window

Not sure of your situation, but if you are using any IoC or dependency injection type stuff, then you'll need to be sure your Views and FieldView things are configured with the appropriate lifetime for the containers, so instances of certain controls don't "hang around" after you think they are dead. If you are not using anything fancy like that, then disregard this comment :)

Hope this helps you narrow down the issue.

-Steve

somanadha

You are newing up your FieldView class and adding without cleaning the listeners from the previous FieldView.

That means the event to which the FieldView registered holding the instance of your old FieldView object.

So the GC can't release your FieldView object as they are registered to your event, even though the FieldView is removed from the Canvas.

I don't your code but this is what you could try

before adding a FieldView to the event for call back, clear the event and add the new FieldView object for listening

innovasoft

ASKER

thank you all for your answers.

I see now, that the object still exists, because it's registered to the event. So I have to unwire them, when I remove the Control.

unfortunately, the way, smickle wrote, doesn't work, because it only unwires the listeners of the new class before it re-registers them again.

So, I had the idea to write a dispose-method where all the events will be deregistered. The problem is, when I replace the

parent.Children.Clear();

Open in new window

with

for (int i = parent.Children.Count - 1; i >= 0; i--)
{
    UIElement el = parent.Children[i];

    if (el is IDisposable)
        ((IDisposable)el).Dispose();

    parent.Children.Remove(el);
}

Open in new window

it takes hours to remove the field. Is there a nicer way? Maybe I should do this with parallel tasks?

innovasoft

ASKER

by the way:

@jagrut: no, the events aren't static

@smickle: no, I don't use any dependency injection stuff

smickle

For your Dispose idea, you may have to just unwire the event in your for loop, if it's possible in scope of this for loop. If the event handler is the only thing that is "holding on" to the instance, then GC should cleanup.

I've had issues before that were similar, but mine involved having to explicitly setting the .Content property of my UIElement to null and unwiring event handlers. But that was SL3 stuff. If you are in Silverlight, then there's a known issue, a memory leak, that is kinda sorta related to all of this. It is being fixed in SL5. The known issue is only in SL and not WPF. So if you are in WPF, then you can rule that out.

Here is info on the known bug in SL that causes memory leaks:
https://connect.microsoft.com/VisualStudio/feedback/details/632838/sl-gc-stress-test-memory-leak

ASKER CERTIFIED SOLUTION

innovasoft

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

innovasoft

ASKER

didn't solve the problem