TEXT_SetText() doesn't invalidate window

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • TEXT_SetText() doesn't invalidate window

      C Source Code

      1. TEXT_Handle hTxt = WM_GetDialogItem(hWinMain, TEXT_TITLE);
      2. char s[64];
      3. GUI_RECT rect;
      4. printf("\n\n\n");
      5. TEXT_GetText(hTxt, s, sizeof(s));
      6. printf("TEXT_GetText(%ld)=%s\n", hTxt, s);
      7. if (WM_GetInvalidRect(hTxt, &rect) == 0) {
      8. printf("WM_GetInvalidRect(%ld)=0\n", hTxt);
      9. } else {
      10. printf("WM_GetInvalidRect(%ld)=1\n", hTxt);
      11. }
      12. TEXT_printf(hTxt, "Registro %d..%d/%d", first_entry + 1, first_entry + num_entries, log_size);
      13. TEXT_GetText(hTxt, s, sizeof(s));
      14. printf("TEXT_GetText(%ld)=%s\n", hTxt, s);
      15. if (WM_GetInvalidRect(hTxt, &rect) == 0) {
      16. printf("WM_GetInvalidRect(%ld)=0\n", hTxt);
      17. } else {
      18. printf("WM_GetInvalidRect(%ld)=1\n", hTxt);
      19. }
      20. printf("\n\n\n");
      Display All
      Output is

      Source Code

      1. TEXT_GetText(92)=Registro eventi
      2. WM_GetInvalidRect(92)=0
      3. TEXT_GetText(92)=Registro 1..2/9
      4. WM_GetInvalidRect(92)=0
      How is possible that TEXT widget area is not invalidated after setting a new text? Indeed I don't see any visible changes.
      If I call WM_InvalidateWindow() on the widget, the behaviour is correct and I see the new text in the TEXT widget.

      It's an oddy behaviour, because it may depend on the first text set during TEXT_CreateEx(). I create the TEXT widget with the following code:

      C Source Code

      1. TEXT_Handle hTxt;
      2. hTxt = TEXT_CreateEx(TOPBAR_LEFT_WIDTH, 0, xSize - 2 * TOPBAR_LEFT_WIDTH, TOPBAR_HEIGHT, hWin, WM_CF_SHOW, TEXT_CF_HCENTER | TEXT_CF_VCENTER, TEXT_TITLE, "Registro eventi");
      3. TEXT_SetBkColor(hTxt, GUI_RED);
      4. TEXT_SetTextColor(hTxt, GUI_WHITE);
      5. TEXT_SetFont(hTxt, TOPBAR_FONT);
      If I change the text in TEXT_CreateEx() it is possible that afterwards TEXT_SetText() will invalidate the widget and the new text is drawn.

      It seems to me it depends of the length of the old and new string: if they are the same, TEXT_SetText() sometimes decides to not invalidate the text area.
    • I read somewhere in the forum that there was a bug exactly with TEXT_SetText() when the length of the text does not change. I think I encountered it.

      Could you give me more details of which versions are affected of this bug? I read that 6.18c fixed this bug.

      I noticed this bug on a simulator under Windows (SeggerEval_WIN32_MSVC_MinGW_GUI_V616.zip). I'm using it because my embedded platform is equipped with MCU from NXP and the emWin last emWin release is v6.16c. Is this version affected of this bug?
    • I experienced the same problem with v6.16c (NXP binaries), so this bug is present at least since this version.
      Unfortunately the last NXP emWin binary is v6.16c, so I can't upgrade.

      What do you think of this workaround?

      Source Code

      1. #if (GUI_VERSION >= 61603) && (GUI_VERSION <= 61803)
      2. TEXT_GetText(hTxt, old_txt, sizeof(old_txt));
      3. size_t old_len = strlen(old_txt);
      4. size_t new_len = strlen(new_text);
      5. if (new_len == old_len) {
      6. TEXT_SetText(hTxt, "");
      7. }
      8. #endif
      9. TEXT_SetText(hTxt, new_text);
      Writing this piece of code, another question arose. Is it possible to know the length of a text in a TEXT widget? TEXT_GetText() copies the text of a TEXT widget in a buffer, but I don't know how to size this buffer in advance. I think it should be nice to have a TEXT_GetTextLen().
    • Hi,

      You are right, there was a bug related to setting a new string with the same length as the old string. If that's the case the widget wasn't invalidated.

      Your working is almost good. Instead of setting an empty string I would simply mark the window as invalid and tell its parent about the changed text (if required).

      C Source Code

      1. #if (GUI_VERSION >= 61603) && (GUI_VERSION <= 61803)
      2. TEXT_GetText(hTxt, old_txt, sizeof(old_txt));
      3. size_t old_len = strlen(old_txt);
      4. size_t new_len = strlen(new_text);
      5. if (new_len == old_len) {
      6. WM_InvalidateWindow(hTxt);
      7. WM_NotifyParent(hTxt, WM_NOTIFICATION_TEXT_CHANGED);
      8. }
      9. #endif
      10. TEXT_SetText(hTxt, new_text);
      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Do you confirm that this bug appeared for the first time in 61603 (6.16c)?

      Is it safe to call WM_NotifyParent() before TEXT_SetText()? Shouldn't it be better to call it after?

      Source Code

      1. #if (GUI_VERSION >= 61603) && (GUI_VERSION <= 61803)
      2. TEXT_GetText(hTxt, old_txt, sizeof(old_txt));
      3. size_t old_len = strlen(old_txt);
      4. size_t new_len = strlen(new_text);
      5. if (new_len == old_len) {
      6. WM_InvalidateWindow(hTxt);
      7. }
      8. #endif
      9. TEXT_SetText(hTxt, new_text);
      10. #if (GUI_VERSION >= 61603) && (GUI_VERSION <= 61803)
      11. if (new_len == old_len) {
      12. WM_NotifyParent(hTxt, WM_NOTIFICATION_TEXT_CHANGED);
      13. }
      14. #endif
      Display All
    • Hi,

      it seems the bug was introduced with V6.12.

      My fault, better call the WM_NotifyParent() after setting the new text.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.