June CTP Changes to Control Widths and Heights
As we get nearer to finally shipping V1, we’ve been pretty hardcore about minimizing the number of breaking changes that we let into the product. Most of the changes we make these days are straight bug fixes or performance optimizations. That said, among the more impactful changes that we made from Beta 2 to June CTP is the removal of a series of triggers in our control styles that set the MinWidth and MinHeight properties on the controls.
The Old BehaviorÂ
These triggers, which existed in the templates for many of our controls,ensured a “default†sized control when no explicit width or height had been set. The result was that a plain Button tag produced a button that was 75×23.Â
Originally, we were just setting the MinWidth and MinHeight properties directly, but they were preventing people from changing the size of the control below to be smaller than the default size, a pretty agregious bug.
The New Behavior
We removed these triggers. Now, a plain button tagwill produce a button that is approximate 4×4 (as a result of the borders and padding on the control itself). It will now be necessary for developers to set a width and a height on the button directly.Â
Motivation for this Change
We saw multiple problems resulting from the old behavior. Fundamentally, those triggers were overloading the meaning of the value “Auto†in a way that produced inconsistent and problematic behaviors. Specifically:
1. Problems related tooling. Feedback from our tooling partners was clear that the behavior was extremely difficult to tool. The triggers forcing them to write special case code and even with that, there were certain design time sitautions that caused a control to potentially jump around the scene depending on how it was positioned within the designer.
2. Bugs related to styling the MinWidth / MinHeight property The old behavior had the side effect of making it impossible for a user to set MinWidth or MinHeight properties from a style. This was because our triggers were declared with the template which took precedent over the style.
3. Inconsistent layout experience between controls and other elements such as shapes and panels. Finally, controls were the odd man out in terms of layout. No other elements in the platform had this special sizing behavior.
Workarounds
Now, controls will behave like other elements in the platform. The simple workaround for this change is to use a style or local value to set the correct layout properties as necessary. You may, for example, want to explicitly set the MinWidth or MinHeight directly on the controls you use now.
July 2nd, 2006 at 12:15 am
You should communicate this breaking change to Charles Petzold. His recent blog entries on the June CTP mentions how this affects the examples in his upcoming book.