Too small editable field in a TextBlock


We had gotten some bad visual experience with editable fields in the latest version of GoJS.
In earlier versions, this was not a problem.
Our application is much based on the flowchart-sample, where we use a textblock inside a shape like this:

name: “TEXT”,
font: someFont,
text: “”,
isMultiline: true,
stroke: someTextColour,
margin: 8,
wrap: go.TextBlock.WrapFit,
editable: true

As you can see, we always default start with an empty text, and can add this by double-clicking. This part works well.

In earlier versions of GoJS(like v1.2) it appeared like this:

As you can see here, the initial editable box is quite small, but grows perfectly fine with entered text.
And with lost focus at the end, the shape is perfectly resized to fit the text.
Everything was the way we liked it…

Then at some point, something happened. I am not sure what version did what, but with v1.4.27, it looked like this:

Notice that the start is the same, but entering text makes the text appead downwards, and it looks quite bad.
At the end, leaving the text, updates the shape, and all looks good again.

Now, with the latest GoJS v1.5.10, it is even worse.

Look at the initial textbox. It is suddenly much smaller.
And the biggest problem is when you start typing the same text as above. The field never expands, and there is only room to see the last 1 or 2 characters. The rest dissapear up and out of view.
Also this time, it renders fine when leaving the box. But the appearence for the user in meantime is horrible.

I also see the same type of behaviour in the latest flowchart-sample.
If you drag in one of the blue figures with a initial short text, double-click and edit the text to a much longer one, it does not look good anymore. (Until lost focus)

Can anyone explain why this has become like this with the latest versions of GoJS, and more important, will this be fixed in future releases? Or is it some other easy way to handle this in a better way?

I see. The first update was an attempt to respect wrapping, but we must be presuming that the textblock is width-constrained too often.

We’ll investigate this.

This should be improved in 1.5.11, which we have just released as “latest”.

Thanks. It looks better now.