EtoCollapsibleSection height glitch

I am having a problem where users report that eto content UI hosted in the material & texture panels is truncated in height. What should look like this (and does, for me):

Ends up on my user’s machines like this:

Problem is, I have not been able to reproduce this, neither in V6 or V7, nor on Windows or Mac. I built against Rhino from a few weeks ago, no problem there, updated to current RC, no problem, uninstalled and installed current SR, still no problem. Made sure to delete all settings for Rhino and RDK-related plugins, still no repro.

The panel, inherited from EtoCollapsibleSection, is used for all Bella nodes, with the relevant code looking like this:

    public override int SectionHeight => _outerTable.Height;

    public void AddFinalStretch()
        _outerTable.Rows.Add(new Eto.Forms.Label());

    public ContentUI(IContent renderContent)
        RenderContent = renderContent;

        Padding = new Eto.Drawing.Padding(0);

        _currentExpander = new UI.Expander();

        Content = _outerTable = new UI.TableLayout
            Rows = { _currentExpander }


        Builder.ParseNode(renderContent.Prototype, Excludes, null, this);



        DataChanged += OnDataChanged;

Since I am unable to reproduce here, not sure what else I can tell you. I will say that even here, when I collapse one of my own headers implemented in eto, the hosting content UI section does not get the message and update, so it ends up like this:

This apparently never updates for the type of content in question, not when docking/undocking the materials panel, nor switching to some other type of material and back. So maybe that is related.

So the question would be, is there something I am missing, that can explain this working everywhere I try it, but failing elsewhere.

Rhino/Eto gaslighting you? :wink:

1 Like

@maxsoder, can you have a look at this?

It appears related to setting window scaling in Windows, and as of about an hour ago, I think I have a workaround. It’s a bit strange, because it appears that if I set the Height of controls, I need to use that height * Screen.PrimaryScreen.Scale, when (recursively) computing a final panel height for a panel consisting mainly of many nested TableLayouts.

I’ll write back here again if/when I have time to look further into this and find out what’s really going on.


I use the below code myself. The MFC holder is not able to automatically detect the ETO height, so I check if we are running in Windows and if that is the case then I use the LogicalPixelSize on my main tables height. On the Mac this is not a problem as the holder is itself implemented in ETO and is able to automatically adjust the heights.

public override int SectionHeight
    if (HostUtils.RunningOnWindows)
      float dpi = ParentWindow != null ? ParentWindow.LogicalPixelSize : 1.0f;
      return (int)((m_table.Height + 2 * m_table_padding_int_value) * dpi);
    return m_table.Height + 2 * m_table_padding_int_value;
1 Like

Thanks a lot, I have a workaround, but will want to give this a try instead.