Table Panel blank space issue_

Hello, I have an issue with the table panel. When there is a TextBlock inside as a separate row then it adds some extra blank space after the text block. The amount of the extra space depends on how long the text is. How to prevent this space from appearing?

Here’s an example code. The first shape is simulating a simple button. The second row represents a header. And the third row represents content which is expected to fill the remaining space. There should be no extra blank space between rows.

Screenshot:

Code example:

<!DOCTYPE html>
<html lang="en">
<body>
<script src="https://cdn.jsdelivr.net/npm/[email protected]/release/go-debug.js"></script>
          
<div id="sample">
  <div id="myDiagramDiv" style="border: solid 1px black; width: 400px; height: 400px"></div>
</div>

<script id="code">
  const myDiagram =
    new go.Diagram('myDiagramDiv');

  myDiagram.groupTemplate =
    new go.Group('Spot', {
      desiredSize: new go.Size(100, 200)
    })
      .add(
        new go.Panel('Table', {stretch: go.Stretch.Fill})
          .add(new go.Shape({
            stroke: "black",
            fill: "white",
            row: 0,
            desiredSize: new go.Size(20, 20)
          }))
          .add(new go.TextBlock({
            text: "Some text Some text Some text",
            row: 1,
            stretch: go.Stretch.Horizontal
          }))
          .add(new go.Shape({
            stroke: "black",
            fill: "white",
            row: 2,
            stretch: go.Stretch.Fill
          }))
      );

  myDiagram.model = new go.GraphLinksModel(
    [
      { key: 1, text: 'Alpha', color: 'lightblue', isGroup: true },
    ],
    []
  );
</script>
</div>
</body>
</html>

This is a somewhat fundamental problem we’ve had with Table panel. The TextBlock is measuring with a very skinny width, and wrapping, and then giving its row a tall height.

Later in the algorithm, the single column is afforded a large width (because there is 1 column in a Table with desired width of 100). As the column expands, the TextBlock remeasures to be much wider, and much less tall. But it has already made its row (row: 1) very tall. That row never gets a chance to be smaller, we have no rule for that, and we were unable to add one that respected all the other rules we’ve had for Table panel over the years.

So the reason for the area is that the TextBlock originally measures something like this:

  myDiagram.nodeTemplate =
    new go.Node('Table', {
        // desiredSize: new go.Size(100, 200)
      })
      .add(
        new go.Shape({
          fill: "red", row: 0,
          desiredSize: new go.Size(20, 20)
        }),
        new go.TextBlock({
          text: "Some text Some text Some text",
          row: 1, background: "lime",
          stretch: go.Stretch.Horizontal
        }),
      );

You have a few options for fixing this. One is to force that middle row to have a well-defined width, possibly the same width as the Table itself:

  myDiagram.nodeTemplate =
    new go.Node('Table', {
        desiredSize: new go.Size(100, 200)
      })
      .add(
        new go.Shape({
          fill: "red", row: 0,
          desiredSize: new go.Size(20, 20)
        }),
        new go.TextBlock({
          text: "Some text Some text Some text",
          row: 1, background: "lime",
          width: 100 // Instead of stretch
        }),
        new go.Shape({
          fill: "blue", row: 2,
          stretch: go.Stretch.Fill
        })
      );

Of course, if you are using a data-binding to define the table desiredSize (width), you can add a corresponding data-binding on the TextBlock. But if you have multiple columns in your Table panel, your solution might be more complicated.

If that’s unsuitable in your particular case, we might need more details to help you make a workaround for it. But the fundamental issue is that TextBlocks with stretch values that stretch into not-well-defined spaces may have to remeasure, and their rows/columns may not be able to reflect these remeasurements. It’s easy to make simple cases (like only one column) work here, but a general rule that satisfies all more complex cases get more difficult.

We consider this a known issue, we even considered making a more straightforward Table panel type with fewer rules, but we have not done so yet.