Message boxes with long unbreakable strings show empty

[Arty]

When a message box text contains a string that doesn't fit into one line but can't be broken automatically, then the message box appears empty.

I already checked out what the issue is: MultilineTextarea does the anchor calculation with unsigned ints, so the anchor gets a huge positive value instead of the proper negative value, when an unbreakable string is too long. Then the drawing routine draws the empty space out there.

Probably not be the only place where such a calculation goes wrong. I'll check it out thoroughly and fix it.

[GunChleoc (gunchleoc)]

Expected behavior at the moment should be a truncated string - the font renderer can't handle breaking of longs strings without blank space yet. I'm working on that problem, but that will be a big branch.

[Arty (artydent)]

Committed a small fix.

Aside from fixing types to avoid overflow in the anchor calculation, I also set the anchor to 0 when it would become negative, otherwise the longest unbreakable string would be properly aligned but all the short strings would be off (even outside of the visible area if the long string was long enough).

So now the short lines are aligned as they should, but overlong unbreakable lines are automatically aligned left and truncated right. I think that's good enough, it's truncated somewhere anyway.

(To also align the long lines properly, I briefly considered adding an additional sweep in the font renderer to re-adjust the position of short lines when overlong lines were present, but I didn't feel comfortable enough to mess around in the renderer, possibly breaking other stuff in the process.)

[GunChleoc (gunchleoc)]

I am having trouble with confirming the bug. Which screen did you get this in?

[Arty (artydent)]

There isn't a definite screen where this always happens. I noticed it by accident when I tested the error messages in my robust-saving-branch. At one point it showed an empty message box, and it turned out that that the path string shown in the error message was "too long" (happens easily with long map names) and triggered this.

[GunChleoc (gunchleoc)]

OK, hard to reproduce then.

BTW we only set bugs to "Fix Commited" when the fix has reached trunk, so this is still "In Progress"

[GunChleoc (gunchleoc)]

Fixed in build20-rc1