You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently 2 bugs related to how MGComponent<TElementType> instances are measured:
1. The component measuring logic is not robust enough to account for cases where multiple components of the same control must share their measurement with the control's Content
Suppose you created a control called MGHeaderFooterPresenter which was structured something like this (but using MGComponent<TElementType> to apply the layout instead of actually using an MGDockPanel):
MGComponent<TElementType> allows a component to share its width with the control's Content, but does NOT allow it to share width with other components inside that same control. So you end up with an incorrect measurement that's something like this: int Width = Max(Sum(components that share width with content), ContentWidth);
Currently, the only control that this seems to affect is MGListBox which has 2 components, 1 for the title header, and 1 for the rows of content. MGListBox intentionally does not measure the title's width when measuring itself in order to avoid this bug (which in turn means the MGListBox might not be wide enough in cases where the title would normally be wider than the rows)
2. The component measuring logic incorrectly handles Padding
If the component does not use the owner's Padding for its measurements (MGComponentBase.UsesOwnersPadding = false, such as for the tab headers of an MGTabControl where the Padding of the MGTabControl only affects the content region), then the measurement logic may incorrectly add the Padding to the end result in cases where it shouldn't.
Suppose we're measuring an MGTabControl where the tab headers are docked to the top. If the tab headers are 100px wide, the tab content is 50px wide, and the Padding is 20px, the total width should be:
intWidth= Max(100,50+20);
But the Padding is being automatically applied to the result before any components are measured, so we currently end up with:
Meaning we get an incorrect result in cases where the component shares width with the content, AND the component is wider than the content, AND the component does not respect the control's Padding.
To demonstrate this issue, create a window with the following layout:
After fixing these bugs, we should also modify MGListBox<TITemType>'s constructor to set the title component's ConsumesLeftSpace to true since listboxes currently don't account for the title bar's width when measuring their entire width:
There are currently 2 bugs related to how
MGComponent<TElementType>
instances are measured:1. The component measuring logic is not robust enough to account for cases where multiple components of the same control must share their measurement with the control's
Content
Suppose you created a control called
MGHeaderFooterPresenter
which was structured something like this (but usingMGComponent<TElementType>
to apply the layout instead of actually using anMGDockPanel
):If the
HeaderPresenter
andFooterPresenter
are both components of the control, the total width of the control would need to be:MGComponent<TElementType>
allows a component to share its width with the control'sContent
, but does NOT allow it to share width with other components inside that same control. So you end up with an incorrect measurement that's something like this:int Width = Max(Sum(components that share width with content), ContentWidth);
Currently, the only control that this seems to affect is
MGListBox
which has 2 components, 1 for the title header, and 1 for the rows of content.MGListBox
intentionally does not measure the title's width when measuring itself in order to avoid this bug (which in turn means theMGListBox
might not be wide enough in cases where the title would normally be wider than the rows)2. The component measuring logic incorrectly handles
Padding
If the component does not use the owner's
Padding
for its measurements (MGComponentBase.UsesOwnersPadding = false
, such as for the tab headers of anMGTabControl
where thePadding
of theMGTabControl
only affects the content region), then the measurement logic may incorrectly add thePadding
to the end result in cases where it shouldn't.Suppose we're measuring an
MGTabControl
where the tab headers are docked to the top. If the tab headers are 100px wide, the tab content is 50px wide, and thePadding
is 20px, the total width should be:But the
Padding
is being automatically applied to the result before any components are measured, so we currently end up with:Meaning we get an incorrect result in cases where the component shares width with the content, AND the component is wider than the content, AND the component does not respect the control's
Padding
.To demonstrate this issue, create a window with the following layout:
Result:
The
TabControl
ends up being 42px too tall. (40px of thePadding
's Top+Bottom, and 2px of theBorderThickness
Top+Bottom)To fix these bugs, the following methods should be refactored:
After fixing these bugs, we should also modify
MGListBox<TITemType>
's constructor to set the title component'sConsumesLeftSpace
totrue
since listboxes currently don't account for the title bar's width when measuring their entire width:Before bugfix:
After bugfix:
The text was updated successfully, but these errors were encountered: