Height of Controls
Updated May 2018
When row coordinates are converted to pixels, the height of the visible control is often shortened slightly—i.e. the bottom coordinate shifted up—to allow for some space between rows, i.e. external leading. This topic describes the rules for this adjustment in more detail.
When the erow coordinate is expressed using regular rows, not millirows or pixels, then the control height will not include the external leading; i.e. it will be shortened by the number of pixels in the External Font Leading value. The one exception to this rule is for Edit Controls (INFLD) when the Allow Edit Boxes to Use Leading Space option is checked.
Conversely, when the erow coordinate is expressed in millirows or in pixels, then the height of the control will be as specified without adjustment, i.e. the height will include the external leading.
This sounds confusing but makes sense, based on the following reasoning:
| • | When using regular row units, it is common to put controls in adjacent rows, particularly when converting from a text-based layout. In order for these to not appear too crowded, especially for buttons and other controls that have their own borders, it seems logical to preserve the same external leading area that would appear between text rows. |
| • | But, when using millirows, the idea is that row N occupies millirows N*1000 to (N+1)*1000-1—e.g., row five spans millirow 5000 to 5999.) Thus, if you actually asked for a control to occupy millirows 5000 to 5999, you would expect it to be right up to the edge of another control that started in millirow 6000. It would seem too confusing if the system automatically converted your request for a control spanning millirows 5000-5999 into one spanning millirows 5000-5850 in order to preserve the leading area. The same goes for coordinates specified in pixels. |
