Right now, our Popup class has the notion of an affiliate component, which effectively ties the popup to that component. Specifically, it aggressively closes the popup if the "showing" state of the affiliate changes, the absolute location of the affiliate changes, or the ancestry of the affiliate changes. This behavior dictates that PopupSkin listen for events from the whole ancestor hierarchy of the affiliate component, which is arguably not the prettiest thing in the world to do. We're considering bagging this concept, but I wanted to see what you guys thought. Consider the following points:
Arguments in favor in keeping this concept: * Eliminating this would mean that if you programatically caused the affiliate to move, the popup would be out of place. Take, for example, a ListButton. The user clicks to open the popup, then your application gets a data update from a messaging service you've set up, causing you to update the UI and causing the ListButton to move down. Now, the popup looks "disconnected" from the button that opened it. Arguments in favor of eliminating this concept: * WPF explicitly documents that it does not handle this. Users of this list can attest to how Swing handles it, but my guess is that they don't. So other toolkits have punted, which gives us precedence to do so as well. After all, the use case listed above is a corner case that won't happen very often. * The affiliate concept as it's currently defined adds to the complexity of the class, both in terms of design and implementation. It's not a "one-size-fits-all" tool, already having caused us to keep on adding definitions of what it means for a popup to have an affiliate, which is often indicative of a misguided design. Thoughts? -T
