My theory is that the BBS is somehow dynamically creating columns in the grid or tree at runtime, but not manually disposing of them when it's unloaded.  DevExpress basically expects you to dispose of everything, so I'm wondering if somehow the BBS is still linked to the DevExpress controls and preventing them from being released from memory correctly.  Is this a possibility?

I can open and close a test form I have created without filling the BO that is linked to the BBS, and it releases all memory correctly when the form is closed.  If I fill the BO when opening the form, it will not release all memory once closed.  Any ideas here?

No, sorry.  You have been around for a while and probably remember that we (MicroFour) were initially using DevExpress controls in our medical application and is why we initially created the DevExpress wrapper.  We wrote a single piece of our medical application and experienced massive memory leaks and very poor performance.  It became so bad that we could not release our product using DevExpress and that is when we wrote more SF controls and Themes got introduced.

The BBS follows .NET binding standards and does not create anything within the grid.  If the DevExpress grid is not releasing the binding, this is on the DevExpress side...period.  The BBS does nothing more than implement the IBindingList interface and then expose a unique BO with the strong-typed properties from the wrapped BO.  But if the BBS is properly managed, the Dispose should be picked up and cleaned up through the garbage collector.

As a side note here, we have hundreds of Custom BBS classes in our medical application and we have no memory leaks and we deal with massive amounts of data throughout the life of a session.  So I would never say that there is no possible way that the BBS may not be getting cleaned up due to an SF bug, but I will say that it is very unlikley.

Possibly.  Now this is generally more attributed to rendering issues, but there is a lot of logic that happens in the instantiation of objects as well as registering itself with the parent container or control as well as the native .NET collections )i.e. garbage collector).  You might wait until a handle is created by testing on the IsHandleCreated or override the OnLoad of the form and fill there.  If you are doing the Fill in a constructor the I could see this being more of an issue.  Finally, Fill from different locations to see where the GC finally recognizes the object.  For example, the Shown event, etc.  This is all going to be related to .NET and the GC versus the management of the BBS and BOs.

But, if I am manually disposing of the BO and the BBS in the FormClosed event, shouldn't this be enough no matter where it's being filled or instantiated? 

Also, what is the proper and recommended way to manage memory as far as StrataFrame objects go?  Should we be manually disposing of things when they are no longer in use or is it ok to leave that to the GC?

Yes.

Not if something holds on to an event or an instance binding and will not release it.

If you drop an instance on the form, the Dispose should be intrinsically called as all BOs inplement the IDidposable interface.  If done in code, then manually Dispose of the object.

<System.Diagnostics.DebuggerNonUserCodeAttribute()> _
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
  If (disposing AndAlso (Not (Me.components) Is Nothing)) Then
    Me.components.Dispose()
  End If

  MyBase.Dispose(disposing)

End Sub

In this particular example, I rarely manually dispose of the object.  And we have this type of code all over the place.  We have hundreds of instances where we have this type of code and it gets cleaned up.  When I was referring to in code, I was talking about as a local like this:

However, it never hurts to manually Dispose() of objects if they are getting "hung up" due to the environment in which they are being used.  So in your case, I would manually Dispose() to see if memory gets cleaned up.  In this case, I would palce all of my logic in the BaseBO in which all of my BOs inherit.  Then this code would be implemented in a single location versus having to be re-written for each BO.  Also, using this approach will not be an issue with the partial class.

Public Class MyBO

  Private MyOtherBO as New BOType

  -----  subs, functions, whatever ----

End Class

Where does MyOtherBO get disposed of?  It's a BO instantiated as a class level variable, inside of another BO.  It should go in the dispose for MyBO, but that is being generated inside the Designer code and will get overwritten if I regenerate the partial.

That is what I was referring to when talking about the BaseBO.  All of your BOs should inherit from a BaseBO that inherits BusinessLayer.  This allows you to provide base level logic for this very type of thing without having to code it for each individual BO and at the risk of the Dispose being overwritten.

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 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.