ComboBox Fluttering

[greuelpirat]

I have an issue, where the combobox-popup flutters using

MaterialDesignColors (Installed versions : 1.2.2)
MaterialDesignThemes (Installed versions : 3.0.1)

I created a github-repo with a demo application:
https://github.com/greuelpirat/ComboBoxFlutterIssue.git

Just start the app and change the selection of the combobox in the bottom right corner at least two times.

[jespersh]

Not sure I'd call it fluttering when it is shaking it hard at about 10 times a second. The gif is limited.

When placing comboboxes near very corners of an application, then I'd use this attribute materialDesign:ComboBoxAssist.ClassicMode="true"

[greuelpirat]

I just lookup up in a dictionary, I am not that good in english. If you have a better description, I take it.

the classic mode works, yes. It also works to set the combobox to a constant width or futher away from the border. so there are some workarounds.

[w-syss]

The combobox switched rapidly between the ClassicContentTemplate and the UpContentTemplate.
This is invoked in the ComboBoxCustomPopupPlacementCallback.

The ClassicContentTemplate and the UpContentTemplate / DownContentTemplate have a width difference of two pixels (this is important later on).

There are calculations in the ComboBoxCustomPopupPlacementCallback to decide which template should be applied. The issue here is, that the calculations are made for the currently applied template not for the new template.

The appropriate template is applied by setting the Template property of the Child property. This again causes the ComboBoxCustomPopupPlacementCallback to be invoked, this time calculating for the now changed template. In most cases the calculations in the ComboBoxCustomPopupPlacementCallback return the same values, since the templates are similar enough, but as i mentioned earlier, there is a two pixel difference between the ClassicContentTemplate and the UpContentTemplate / DownContentTemplate, leading to this edge case, where the now applied template is causing differing calculation results. This leads to a more or less infinite loop of alternating the templates of the popup.

The simplest solution would be to guarantee that the width of the ClassicContentTemplate and the
UpContentTemplate / DownContentTemplate are equal.

[Keboo]

Great analysis @w-syss. I agree, I think the fix is to first make the templates size match. I think we may also want to revisit the callback to see about options for avoiding the callback loop.

[greuelpirat]

I looked deeper into it and I think I found the callback loop.

The property VisiblePlacementWidth is set here

MaterialDesignInXamlToolkit/MaterialDesignThemes.Wpf/ComboBoxPopup.cs

Line 241 in c0c6d5a

SetupVisiblePlacementWidth(visualAncestry);

And this property is used in the templates PopupContentUpTemplate and PopupContentDownTemplate here

<Grid Grid.Column="1"
  Width="{Binding RelativeSource={RelativeSource AncestorType={x:Type wpf:ComboBoxPopup}}, Path=VisiblePlacementWidth}"
  Height="{Binding ElementName=templateRoot, Path=ActualHeight}"/>

So it uses a property that value depends on its own size.

And because of the margin here

MaterialDesignInXamlToolkit/MaterialDesignThemes.Wpf/Themes/MaterialDesignTheme.ComboBox.xaml

Line 104 in c0c6d5a

<Border Margin="1"

its width grows by 2 every time. And it does not grow to infinite because the template PopupContentClassicTemplate does not use VisiblePlacementWidth at all.

[w-syss]

I feel like this is a bit too much of a bandaid solution. This hardcoded substraction will only cause more confusion in the long run i fear.

I think the real question is: Do we actually need the VisiblePlacementWidth or was it only introduced as a workaround for another issue? I looked at the commit that added it, but the reasoning for introducing it was not very helpful unfortunately.

Removing the VisiblePlacementWidth and using the same width logic for all three templates is the cleanest solution in my opinion.

I think i found a solution for the callback problem, but it will take a couple of days until i have refactored that into an actual commit.

[Keboo]

@w-syss yea I can agree, the combo box placement has been a repeat problem for a while. Personally I would love to try at doing a combo box that does not create a "hole" in the popup for the text box, and instead lifts the text box directly into the popup. It would also help solve several layout rounding problems we have.

With that said, I am happy to look over any potential solution you have. If it make it better, it is a step forward.

[JohnyX]

I still have a problem on 3.2.0 version.

[w-syss]

The current workaround is switching to classic-mode:
materialDesign:ComboBoxAssist.ClassicMode="true".

I would like to tackle this issue at the core and don't add any more bandaid solutions. @Keboo is there a specification for this combobox? The only specification i found was the exposed dropdown menu https://material.io/components/menus#exposed-dropdown-menu. But that combobox looks very different from this implementation.

[greuelpirat]

@w-syss are you still working on this? Otherwise I would work on this.