Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. delegates=strong refs?

delegates=strong refs?

Scheduled Pinned Locked Moved C#
winformsgraphicsdockerdebuggingperformance
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Roger Alsing 0
    wrote on last edited by
    #1

    is this correct regarding delegates (?) : if you have a usercontrol , and make it listen to the parent containers mousemove events (say it hooks itself to the parent in the "parentchanged" event) will the mouse event handlers create a strong ref from the parent to the usercontrol? (i beleve it does) the problem if so , is if you remove the usercontrol from its parent , and loose all references to it. (the only valid ref still alive is the delegate target in the parents mouse event) now , will this usercontrol be garbage collected? (i beleve it doesnt , since ive profiled this with a mem profiler) is all the above correct?? , and if not , how come are the usercontrol still alive and kicking when profiling ,even if i have called gc.collect() after loosing all refs. do i really HAVE TO call .Dispose() on my usercontrol before dropping all refs to it? and if so , is that really good/standard windows forms coding practice? according to msdn you should NEVER call .dispose() unless the target holds valuable resources such as gdi objects , file pointers etc , and never ever do it if you are simply dealing with managed code.. //Roger ps. if you add a Console.Writeline("blah") to the destructor and dispose you can clearly see that they does NOT fire when the usercontrol have attached itself to some parent container events , while if you remove the eventhandlers , finalize and dispose fire just fine...

    C 1 Reply Last reply
    0
    • R Roger Alsing 0

      is this correct regarding delegates (?) : if you have a usercontrol , and make it listen to the parent containers mousemove events (say it hooks itself to the parent in the "parentchanged" event) will the mouse event handlers create a strong ref from the parent to the usercontrol? (i beleve it does) the problem if so , is if you remove the usercontrol from its parent , and loose all references to it. (the only valid ref still alive is the delegate target in the parents mouse event) now , will this usercontrol be garbage collected? (i beleve it doesnt , since ive profiled this with a mem profiler) is all the above correct?? , and if not , how come are the usercontrol still alive and kicking when profiling ,even if i have called gc.collect() after loosing all refs. do i really HAVE TO call .Dispose() on my usercontrol before dropping all refs to it? and if so , is that really good/standard windows forms coding practice? according to msdn you should NEVER call .dispose() unless the target holds valuable resources such as gdi objects , file pointers etc , and never ever do it if you are simply dealing with managed code.. //Roger ps. if you add a Console.Writeline("blah") to the destructor and dispose you can clearly see that they does NOT fire when the usercontrol have attached itself to some parent container events , while if you remove the eventhandlers , finalize and dispose fire just fine...

      C Offline
      C Offline
      Chris Jobson
      wrote on last edited by
      #2

      I think the solution is that if your usercontrol hooks itself to the parent's events it should also unhook itself. If you remove the control from its parent the control will get a ParentChanged event and the Parent will now be null. For example, the following code within the user control seems to work: private Control parent = null; private MouseEventHandler meh = null; private void UserControl1_ParentChanged(object sender, System.EventArgs e) { // Unhook from previous parent (if any) if (parent != null) { parent.MouseMove -= meh; } // Remember new parent parent = Parent; // Hook new parent (if any) if (parent != null) { if (meh == null) meh = new MouseEventHandler(parent_MouseMove); parent.MouseMove += meh; } } Chris Jobson

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups