I understand that sometimes it's very tough to duplicate these kinds of issues in a sample project. But as difficult as it is for you, imagine how difficult it is for us. I mean... at least you have a starting point to work with - you can actually see the problem occuring in your application. :)

There are basically two approaches you can take to duplicating a problem in a sample.

The first approach is to copy your existing application and then try reducing it down to the simplest case by removing pieces of it. In a particular large, integrated application, this can be very time consuming, but it has the advantage of being pretty reliable. The problem is already occurring, so there's no problem reproducing it this way.

The alternative is to start from scratch and create a new project and work upward until the problem occurs. If this works, it's usually quicker and less work, but it can be frustrating because it's often difficult to know which factors in the real project matter.

I usually prefer approach #1, myself. But like I said, I can certainly understand that this might not be practical.

The simplest thing for you to do is just to make sure that the UltraCombo gets disposed before it's data source is Disposed.

Thanks Mike.  I'll just have to techhead my search terms....

Unfortunately it would not be simple to do a sample app as using an MVP framework with several models attached to single presenter and view.  The list members bound to ultracomboeditors are generated within a model depending on model state and passed up through the  presenter. The Filter Panel view acts like an application navigator/state controller, so view panels on different forms are linked to the single application presenter/model set (not sure if this is good architecture, but it works). 

Form shut down does not generate the error, but application shut down does, so that would seem to imply that the underlying presenter is being disposed before one or more Filter Panels.  However, from the stack trace it appears that the panel in question is disposing, and that the event is firing while this is occurring.  However, as noted in the prevous forum item, the stack trace may not be giving the actual process event sequence, so that even though the trace shows the control is disposing, I can for example verify that the 'isdiposed' flag on the container is still false. 

This could just be a timing issue, events need to stop firing when 'isdisposing' is true (which as far as I know is not trapped)  and not wait until components are removed, and 'isdisposed' becomes true.

The two workarounds are to trap for presenter presence, messy IsNot Nothing clauses on every property, or perhaps register the view in the presenter (hmm, have to go back to my MVP model on that) and ensure view disposal prior to presenter disposal, which would seem a cleaner solution.