Issue with TouchGFX 4.17 / STMCubeIDE 1.7.0
A view screen includes a single instance of a custom “TextField�? class and an associated button overlay which, when touched, triggers a popup object, (custom class NumberEntryPopup), which includes a numeric keypad (custom class NumberPad) used to edit the text displayed in the TextField.
NumberPad, in turn, includes a modified version of the TouchGFX example class CustomKeyboard. The original, unmodified CustomKeyboard uses both a foreground and a background image that are switched out when a key is pressed, such that the pressed key is "highlighted" by the background image.
To reduce the keyboard's Flash footprint, the CustomKeyboard class has been modified such that, when a key is touched, instead of switching to a second image, an rectangular outline is displayed surrounding the key.
There are two such outlines, NumberKeyOutline and DeleteKeyOutline, each of which is a TouchGFX container defining a rectangle as a set of 4 TouchGFX "Line" objects. To review, here is the hierarchy of objects in play when the popup and keyboard are displayed:
PasswordView Screen
-> NumberEntryPopup
-> NumberPad
-> CustomKeyboard
-> NumberKeyOutline, DeleteKeyOutline
This scheme has been successfully employed over a long period of time and on numerous other screens as the application under development has progressed. However, in all those cases, there are multple TextFields on each screen, as opposed to the single TextField on the screen in question. And, in the case of a single TextField, when a key on the keypad is touched, the key outline does not appear, and the application fails on an assert() condition.
Through experimentation, I've found that a workaround to the issue is to add a dummy Line object to the offending screen. This simple addition prevents the crash and allows the field to be successfully edited in the popup NumberPad.
Another, somewhat puzzling, workaround is to first view a screen that contains more than one TextField (even without triggering the popup and attempting to edit the field) before viewing the offending screen, in which case, again, the crash is avoided.
So, it would seem that, when generating code for the single TextField screen, the Line object in the CustomKeyboard is somehow not included. This would explain the workaround of adding the dummy line object to the view. But it is rather more difficult to imagine how the visit to a working screen before viewing the offending screen could also correct the issue, especially given the stated TouchGFX model of only retaining a single screen and its resources in memory at a given time.
