neon1

Yes, but as can be seen on line 525 of gwin_widget.c (µGFX v2.8), both are treated the same: if (!text || !*text) gw->text = "";

Hello, I've been troubleshooting a memory corruption issue triggered by keyboard events in a TextEdit widget after gwinSetText() has been used on it. It is probably the same issue described a bit cryptically here: https://community.ugfx.io/topic/415-keyboard-and-textedit-problem/. Of course, as a µGFX newbie I may be simply misunderstanding something, so in that case feel free to tell me off. Reproduction: Create a TextEdit widget. Type some text into it using the (virtual) keyboard. Clear the widget's text by calling gwinSetText(ghTextedit, NULL, FALSE), without changing the focus. Do not tap/touch the TextEdit widget at this point. Type another character => memory corruption (likely causing a crash/hang/whatever). Analysis: Looking at gwin_textedit.c, the cause seems to be that the TextEdit widget does not learn of the fact that its text buffer has been replaced, and thus does not update/reset its cursorPos. cursorPos may then point at a position beyond the new buffer, causing memory corruption the next time a character is inserted or deleted. If the user taps the TextEdit widget after the text has been set and before typing again, the cursorPos is reset to a reasonable value and the issue does not appear. Workaround: Do not use gwinSetText() on TextEdit, but recreate the widget instead. Fix: A clean fix with proper cursorPos resetting would probably require TextEdit to be notified of text changes. A sort-of fix by checking cursorPos before using it is attached. Thanks for creating and maintaining µGFX! It's the best GUI library of its kind that I've come across, and the out-of-the-box virtual keyboard is a killer feature ? – Manuel patch-textedit-cursorpos.diff