Fix Buffer Corruption

[cosmoderp]

Description

Fixes files over 22 characters long in the DWIN screen for the ender3 V2. Adjust buffer for size of the DWIN screen width. Also Set of DWIN_Strings so the the string buffer is not longer than the string.

Benefits

This fixes the over 22 character file name issue that caused buffer corruption. This resolves the high speed and some of the crashes associated with this buffer corruption.

Configurations

configs.zip

Related Issues

#18790

[AnHardt]

DWIN_WIDTH / 8 is the number of symbols/glyphs.
If there is any chance the text is UTF8-text the c-string may need up to 3 bytes per symbol.

[sjasonsmith]

@AnHardt good point. I had recommended this solution because it matches the logic in the calling function, which centers the text on the screen. That didn’t account for multi-byte characters so it slipped my mind.

If not accounted for here, it will crop the string too short.
If not accounted for in the calling function, it will make the text off-center.

It should be easy to confirm that by using some translated file names.

Simply making the buffer larger might introduce issues for single-byte characters if printing strings wider than the display misbehaves.

[enigmaquip]

The T5UIC1 doesn't handle utf8 being sent to it anyways. It'll take ascii or GB2312, it's why all the Chinese text is from a stored image file. It really needs a utf to gb2312 charmap for full language compatability

[sjasonsmith]

If that is the case then it seems we should just ignore any concern for multi-byte characters in this PR.

[enigmaquip]

I don't know that it'll ever need to be that large, but according to the docs the buffer can up to 254 bytes

[sjasonsmith]

the buffer can up to 254 bytes

If we increase the size to 254 there would need to be some testing to see what happens when the string is too wide for the screen, unless you already know...

[enigmaquip]

If we increase the size to 254 there would need to be some testing to see what happens when the string is too wide for the screen, unless you already know...

I have no problem testing if you'd like.
On a side note to that comment the DWIN_WIDTH / 8 doesn't account for that either as DWIN_Draw_String allows you to set the font size as defined in dwin.h
font6x12, font8x16, font10x20, font12x24, font14x28, font16x32, font20x40, font24x48, font28x56, font32x64

[sjasonsmith]

The 8 should really be replaced with a named constant. It exists in DWIN.cpp. It need to move out to a header somewhere son it can be used in both files.

[enigmaquip]

The screen just draws to the end of the screen and omits the rest.
I was wrong on the max size of the buffer, it'd actually be 250 because it's 254 max with the 4 buff tail bytes.
If we wanted to make the buffer only as large as as many bytes as it'd take to draw the max number of characters on screen we'd want
11 + Width / 6 (the smallest font size width) * 2 (the number of bytes for gb2312 encoded characters)

edited to add the 11 (the bytes for the string command itself [mode, colors, x,y])

[sjasonsmith]

You will want to test this change out, but I think this captures the suggestions from @enigmaquip.

(Hopefully you can just click "accept suggestion" to make these changes)

[cosmoderp]

This last one did seem to center stuff better. Some truncation is to be expected when text is too long since you can only ever fit so much on screen.

[thinkyhead]

Thanks! I was looking askance at that array yesterday but got distracted.