• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 501
  • Last Modified:

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

    // then I add the new one

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!
1 Solution
Is the event that FieldView listens to static?
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.

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
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

innovasoftAuthor Commented:
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


Open in new window


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

    if (el is IDisposable)


Open in new window

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

@jagrut: no, the events aren't static

@smickle: no, I don't use any dependency injection stuff
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:

innovasoftAuthor Commented:
actually, I couldn't really fix this. So I just loop through all the children now and dispose them seperately. In the dispose-method, I deregister all the events.

Not nice, but it works.
innovasoftAuthor Commented:
didn't solve the problem
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now