When I try to use the function “lv_label_set_static_text” using long texts, it crashes.
What MCU/Processor/Board and compiler are you using?
ARM Cortex-M4. Kinetis K22
What do you experience?
I am using the function “lv_label_set_static_text” with the long_mode: LV_LABEL_LONG_DOT for the text. The problem is that “lv_label_set_static_text” calls “lv_label_refr_text”, and it try to modify the text (replacing the last characters by dots), but the text is const, so it crashes.
What do you expect?
I think that dots should be added but the text shouldn’t be modified in this case (const text).
Screenshot and/or video
The function “lv_label_set_static_text” has a pointer to a const text as parameter.
I’m not sure what the best approach to solving this is. If we allocate a buffer when using LV_LABEL_LONG_DOT it defeats the whole purpose of using lv_label_set_static_text in the first place. Maybe we shouldn’t allow use of LV_LABEL_LONG_DOT if you are using a static buffer?
I need this feature in my current project, so, I think that the best solution is to allocate a buffer when using LV_LABEL_LONG_DOT with lv_label_set_static_text . This buffer wuould be used only if to add dots is necessary (when the text doesn’t fit). If the text fits properly, the buffer wuouldn’t be used.
That would be almost entirely identical to calling lv_label_set_text with the exact same arguments, hence why I suggested disallowing the use of LV_LABEL_LONG_DOT only with lv_label_set_static_text. Otherwise the name static_text becomes misleading since the static buffer is only used directly in some situations.
OK, in this case the best solution to solve the problem would be your proposal: shouldn’t allow to use of 'LV_LABEL_LONG_DOT` if you are using a static buffer.
What would be the best way of blocking this from a user’s perspective? I’m thinking the following:
When lv_label_set_static_text is called with LV_LABEL_LONG_DOT, set the text, but change the long mode to something else. Or, possibly even set the text to something short and informative like “Error: see docs on LONG_DOT”.
Add a note in the documentation that LV_LABEL_LONG_DOT does not work with lv_label_set_static_text.
Log a warning in the debug log (if it’s enabled).
Do you think that would convey the message well enough that someone wouldn’t have to debug for long to find the problem?
Exactly. I can fix it today or tomorrow; should I apply it to master or dev-7.0? I would think master since it’s clearly broken anyways, but I’m just checking.
I agree with you but, besides, I think that it would be useful to have a function to check if the text fits or not. The user (who is using LV_LABEL_LONG_DOT mode) can check in his app if the text fits using this function. If it fits, he can select lv_label_set_static_text, if it doesn’t fit, he has to use lv_label_set_text.
Obviously, the user must have knowledge of the specifications above discussed.
If the text fits, the exact long mode chosen doesn’t matter, because long modes only come into play when the text no longer fits. Therefore, they would see no visual difference. In the event that it doesn’t fit, we still need a fallback for if the user calls lv_label_set_static_text.
I agree with your logic, but I don’t see a need (or use case) for the extra function. Are you suggesting that they would have to test each of their strings to see if it fit? That seems quite ugly and not worth it. Maybe I’m misunderstanding something.
I was thinking about this some more. There is nothing wrong with the use of lv_label_set_static_text itself; the problem is with the constant buffer passed to it. As long as the buffer is RW, everything should work fine (the buffer will temporarily be modified by the label and restored).
That’s true. The buffer is not necessarily const.
Do have any suggestions in light of that? Leave it as it is and let the user take care of this possible conflict? (Add note to the docs and comment of course.)
Yes. I committed a change to the docs repository the other day that addresses this. But I don’t think anything in the implementation needs to change. The user should just be aware of this problem, and use lv_label_set_text if they really want to use a constant buffer (although, since it allocates a new buffer anyways, it makes no difference in the end).
