Purnell:

This particular issue was actually not specifically an SF issue, however, there have been some pretty significant changes in SF since this post regarding how we clean up handlers.  I wasn't sure exactly what you were asking though.  Sorry for any confusion.

Trent,

Did you have an attachment sample for your solution?

Taylor/ Andria Jensen

Taking a look at this.  Thanks for the sample, it always helps speed up the process.

I have created a sample projects which demonstrates the design I was talking about earlier.  It is using a windows grid, so DevExpress is taken out of the equation.  I have used a BBS as the data source, pointing to the Customers table.  I have two textboxes also bound to the BO.  When the form is closed, it does not come out of memory and there are 11 instances of the BO in memory.  I have also attached a screenshot of the memory profile after closing the form and doing a GC.Collect.  Can you tell me what's going on here?

I have added the below code to my base BO....

Protected DeclaredBOs As New Collection(Of IDisposable)

Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
  If disposing Then
    If components IsNot Nothing Then components.Dispose()
    For Each bo As IDisposable In DeclaredBOs
      bo.Dispose()
    Next

    DeclaredBOs.Clear()
  End If
 
  MyBase.Dispose(disposing)

End Sub

...however, i'm still not seeing the BO getting disposed of properly.  I feel like I have to be missing something.  I have a form with a grid and a textbox on it, both of which are bound to a BO.  The grid is bound through a BBS.  When I close the form, it appears to be hitting all of the appropriate logic to dispose of the BO, but when I look at it in a memory profiler, it shows 5 instances of the BO in memory.  What it seems like it 1 instance for the textbox, and 4 instances for the grid (one for each row of data).  If I only have one row of data in the grid, there is only one instance of the BO. 

SO a couple of questions... why are there so many instances of the BO in memory?  It seems as if it is creating an instance for each control it's binding to, and I would expect one instance only.  Also, is there anything else I could possibly be overlooking in this scenario that would be causing the BO to stay in memory.  I have been looking at this for over a week now and am still not able to pinpoint the cause of why my BOs are staying in memory and not disposing correctly.

 

No problem, glad to help

Duh!  That makes perfect sense.  I've been looking at this stuff too long and couldnt see that solution for some reason.  Okay, I will try that out and see what kind of results I get.  And if I get brave I will try the reflection approach next.  Thanks so much Trent.

Create a method on the BaseBO that adds the BO to a collection, then enumerate through that collection in the Dispose of the BaseBO to dispose of them.  So you would go into the constructor of the inherited BO and add those custom BOs to a collection like this:

Then in the Dispose of your BaseBO, you know what you need to do.  The other option would be to use reflection which gets more complicated, but you wouldn't ahve to do anything within the inherited BOs.  The downside of reflections, though, could be that it could slow things down if not done 100% right.

I am inheriting from my own BaseBO.  I guess I'm just confused as to what would be in the Dispose at the base level.  Would the declared BO be part of a collection of some sort that i would iterate through and dispose?