>... controls [e.g., command buttons, textboxes, etc.] have Resize methods? Even adding a resize method to my subclass of such controls does not automatically fire if I resize a form. :( So much for encapsulating all code within these classes.
>
>I guess what I am looking for are opinions and thought on what would be the best way to handle this while thinking outside the box [i.e., regardless of how we currently have to handle this].
>
>My thought would be that each control have its own resize method and a few more properties to store the original parent container's dimensions, the control's original dimensions and coordinates [top, left]. From there, everything is now relative, the control does not have to be resized or repositioned by some parent's resize method.
>
>Just wondering.

I think this has to do with a Pattern... hmmm... what could it be... let me get this book up here... Looks like the Observor Pattern... This applicability sentence hits me as the most relevent:

When a change to one object requires changing others, and you don't know how many objects need to be changed.

AND the next one:

When an object should be able to notify other objects without making asumptions about who these objects are. In other words, you don't want these objects tightly coupled.

************
I think this pattern is the one that is used with most resizer code. The observer will watch the Size of the form. When the form's (SUBJECT) size changes the Observer will notify registered objects of the state change (form resize), the ConcreteObserver objects (controls) query the Subject for information (size). The, the ConcreteObsorver uses this info to reconcile it's state (adjusts it's own size).
*************

I know in J++ you can do this by raising events in the Controls... you can create a FormResized event in the controls and have the form raise that event when it is resized.

Good luck to ya!

BOb