How to close a window when a button is pressed

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

    • How to close a window when a button is pressed

      I create a child window (child of background window) that has a button. When the button is pressed, in the event WM_NOTIFY_PARENT/WM_NOTIFICATION_RELEASED I call WM_SendMessage() to send a custom message to main/background window.

      During processing this custom message (in the callback of background window), I want to call WM_DeleteWindow() to delete the child window. Is it possible? It seems it works, but after some tests it seems there are some memory leaks.

      I can't call WM_DeleteWindow() from the child window, because only background window knows if it's time to delete the child window.

      I'm using 5.32.

      C Source Code

      1. static void
      2. cbBackgroundWindow(WM_MESSAGE *pMsg)
      3. {
      4. switch(pMsg->MsgId) {
      5. ...
      6. case WM_MYMESSAGE: {
      7. WM_DeleteWindow_ex(pMsg->hWinSrc);
      8. break;
      9. }
      10. default:
      11. WM_DefaultProc(pMsg);
      12. }
      13. }
      14. static void
      15. cbChildWindow(WM_MESSAGE *pMsg)
      16. {
      17. switch(pMsg->MsgId) {
      18. ...
      19. case WM_NOTIFY_PARENT: {
      20. int i = WM_GetId(pMsg->hWinSrc);
      21. switch(pMsg->Data.v) {
      22. case WM_NOTIFICATION_RELEASED: {
      23. if (i == BTN_ID_CANCEL) {
      24. WM_MESSAGE msg = { .MsgId = WM_MYMESSAGE, .hWinSrc = hWin };
      25. WM_SendMessage(WM_HBKWIN, &msg);
      26. }
      27. }
      28. }
      29. }
      30. default:
      31. WM_DefaultProc(pMsg);
      32. }
      33. }
      Display All
    • Hi,

      What you are describing is not a memory leak, but normal behavior of emWin's memory management.

      You can find a description about emWin's memory management in the manual under "Configuration -> Memory management". I have attached an excerpt regarding block management.

      Also, from my point of view there is no need to delete the window by sending a message first, since the message would get handled directly after it has been sent. So it would make no difference if you call WM_DeleteWindow() in instead of sending the custom message.

      Best regards,
      Florian
      Images
      • Memory.png

        86.96 kB, 665×197, viewed 353 times
      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.
    • SEGGER - Florian wrote:

      What you are describing is not a memory leak, but normal behavior of emWin's memory management.
      It was really a memory leak, because after some open and close the child window, emWin crashes for an out of memory error. However I found the solution, it wasn't a problem in emWin, I was creating the window two times, but deleting only one instance.

      Probably the sentence in the manual explains why GUI_ALLOC_GetNumFreeBytes() doesn't return the same number after one WM_CreateWindow() and one WM_DeleteWindow(). This is ok, but the number should be almost the same with the use (opening and closing windows), otherwise a memory leak is really present.

      For this reason, I'd like to know how to monitor emWin dynamic memory to be sure there isn't any memory leak.


      SEGGER - Florian wrote:

      Also, from my point of view there is no need to delete the window by sending a message first, since the message would get handled directly after it has been sent. So it would make no difference if you call WM_DeleteWindow() in instead of sending the custom message.
      Yes, you're right, but the child window doesn't know if the button released event should cause the window close or not. Only the background callback (in another C module) knows it.
    • Hi,

      giusloq wrote:

      Probably the sentence in the manual explains why GUI_ALLOC_GetNumFreeBytes() doesn't return the same number after one WM_CreateWindow() and one WM_DeleteWindow(). This is ok, but the number should be almost the same with the use (opening and closing windows), otherwise a memory leak is really present.
      Have a look at the example below. You will see that the difference between the number of bytes before creating the window and after deleting it is 32 bytes. These are the bytes that hold the block information. If you run these lines in a while loop, the number of free bytes won't decrease over time, but will stay constant.

      C Source Code

      1. NumBytes = GUI_ALLOC_GetNumFreeBytes();
      2. hWin = WM_CreateWindow(0, 0, 480, 272, WM_CF_SHOW, _cbWin, 0);
      3. NumBytes = GUI_ALLOC_GetNumFreeBytes();
      4. WM_DeleteWindow(hWin);
      5. NumBytes = GUI_ALLOC_GetNumFreeBytes();
      The block information will stay persistent until more memory is allocated that would not fit in the location right after where the old block info is. Then, the blocks would get reordered which means the old block info gets removed and a new block is allocated.

      warlord wrote:

      How can user find out if there is a memory leak or not, with such normal behavior of emWin's memory management??
      Generally, you can monitor emWin's memory using these routines:
      - GUI_ALLOC_GetMaxUsedBytes()
      - GUI_ALLOC_GetNumFreeBytes()
      - GUI_ALLOC_GetNumUsedBytes()

      There is also GUI_ALLOC_GetMemInfo() which fills a structure that holds all relevant data about the memory usage.

      Best regards,
      Florian
      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.