EtoCollapsibleSection height glitch

Rhino Developer
, ,
1

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):

image
image540×642 18.1 KB

Ends up on my user’s machines like this:

image
image1090×917 24.2 KB

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();
        _expanders.Add(_currentExpander);

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

        _outerTable.SuspendLayout();

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

        AddFinalStretch();

        _outerTable.ResumeLayout();

        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:

image
image364×506 6.08 KB

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.

2

Rhino/Eto gaslighting you? :wink:

1 Like
3
4

@maxsoder, can you have a look at this?

5

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.

6

Hi,

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
{
  get
  {
    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
7

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