Dynamically Creating User Controls That Fire Events Back To You

re: Dynamically Creating User Controls That Fire Events Back To You

donmarais — Thu, 14 May 2009 13:37:24 GMT

Jesse,

I have a complex situation with nested children objects being loaded into UI to create a an image display. The parent is MyControl. It loads a child, MyTemplate, which in turn loads in MyBox, which in turn opens a popup, depending on user selection of image. Popup has close button and button to select image. Select image event handler to close all of MyControl's children and load in MyEditor in its place. Incidently, MyControl has a grid Main, into which all these children are being loaded in. However, all that happens is that popup is closed. Someone suggested using delegate events to call a method on MyControl to close its children and load in MyEditor. Can you provide an example of how to do this please?

re: Dynamically Creating User Controls That Fire Events Back To You

jesseliberty — Sat, 10 May 2008 20:41:50 GMT

Ben,

I double checked, you do not have to take extra steps either to ensure that the parent page will receive the notification, nor to ensure that the control will be destroyed; simply fire the event and remove the control from the parent's collection and it will work as it should.

re: Dynamically Creating User Controls That Fire Events Back To You

BenHayat — Thu, 08 May 2008 21:20:10 GMT

>>or is the fact that the page is registered with the event handler enough to keep it alive. For this, I need to make inquiries.<<

This is something that's been in my head. So I figured, just to be on the safe side, I'd do two extra step to ensure the object and it's original reference has been destroyed, one by deregetering the event and secondly setting the reference (auc) to null. Because if the user clicks on the create button again, a new object is created and is hooked up to reference and then gets added to children.

When I used to write in Delphi for Win32 (which didn't have it's own GC), we had to be very careful about leaving objects around.

Thanks to you, this blog has been very valuable [to me at least].

re: Dynamically Creating User Controls That Fire Events Back To You

jesseliberty — Thu, 08 May 2008 15:15:42 GMT

>>Even though I may still have my original Reference auc hanging around, but that doesn't mean it's pointing to the old object any more. And if it is not, then GC will eventually remove the auc too.<<

You certainly did. Now, the question is whether I have the order of operations correct and what happens if there are no other references to that object... that is, if the GC cleans up the object is there a chance it won't fire its event, or is the fact that the page is registered with the event handler enough to keep it alive. For this, I need to make inquiries.

Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew — Thu, 08 May 2008 13:19:09 GMT

Pingback from Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew

re: Dynamically Creating User Controls That Fire Events Back To You

BenHayat — Thu, 08 May 2008 03:33:44 GMT

Oh wait, let me take back my previous question.

When we add a User Control to a collection (even though as part of the constructor, we pass the reference to that object to the collection (auc)), but from that point on, the collection now maintains (as you said) a new internal reference to the User Control object and then when we remove the object from collection, the internal collection reference and the User Control object are destroyed. Even though I may still have my original Reference auc hanging around, but that doesn't mean it's pointing to the old object any more. And if it is not, then GC will eventually remove the auc too.

Did I get right?

re: Dynamically Creating User Controls That Fire Events Back To You

BenHayat — Thu, 08 May 2008 03:22:53 GMT

>>No, there is no necessity for that. In fact, you'll notice that I reuse that reference to point to a second instance. The reference is maintained by the colleciton and when I remove it from the collection, there is no longer a refernece to it.<<

So, you're saying when we create a User Control and add the reference to Grid's collection the User Control gets created and then when we remove the reference from from the collection, the actual User Control gets destroyed.

And if I add that reference back to the collection, the user control object gets created again?

re: Dynamically Creating User Controls That Fire Events Back To You

jesseliberty — Thu, 08 May 2008 03:00:02 GMT

>> The only way for GC to see that, is if auc=null <<

No, there is no necessity for that. In fact, you'll notice that I reuse that reference to point to a second instance. The reference is maintained by the colleciton and when I remove it from the collection, there is no longer a refernece to it.

I don't know if having the registration on the event handler matters; I suppose it must because the page has to be able to get to the event even though the control has been removed from its children collection. I'd have to look into the order of operations, but it would be a simple matter to deregister it while cleaning up.

In any case, no problem; it was a fun project and a good blog topic. I'll come back to it with more time and make it into a video at some point.

re: Dynamically Creating User Controls That Fire Events Back To You

BenHayat — Thu, 08 May 2008 02:40:12 GMT

>>Sweet<<

You took the words out of my mouth...

I'm stunned! In such a short time since my response, you cooked up all these codes and explanations. My hat off to you Jesse.

Let me first thank Nick and yourself for going over board to answer my question. I'm a bit embarrassed and didn't ask for all this.

Secondly, I have a question which I also discussed it with Nick;

Here in this code which is part of the Page, you register the auc.Closed Handler:

auc.Closed += new AddressUserControl.AddressEventHandler(auc_Closed);

And here in the UserControl:

parent.Children.Remove(this);

You remove the UserControl from it's parent.children.

My question is, just by removing the child from the parent, is no indication to GC to permanently "destroy" the UserControl (auc). The only way for GC to see that, is if auc=null. However, for GC to do that it has to make sure there is no reference to that object or it's internal. So shouldn't we also do the following as part of the closing?

auc.Closed -= new AddressUserControl.AddressEventHandler(auc_Closed);

Personally, I would remove the UserControl (auc) and setting it to null, in the parent Page when responding to Closed.