How to close a window when a button is pressed

giusloq · Mar 4th 2021, 5:00pm

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

static void
cbBackgroundWindow(WM_MESSAGE *pMsg)
{
switch(pMsg->MsgId) {
...
case WM_MYMESSAGE: {
WM_DeleteWindow_ex(pMsg->hWinSrc);
break;
}
default:
WM_DefaultProc(pMsg);
}
}
static void
cbChildWindow(WM_MESSAGE *pMsg)
{
switch(pMsg->MsgId) {
...
case WM_NOTIFY_PARENT: {
int i = WM_GetId(pMsg->hWinSrc);
switch(pMsg->Data.v) {
case WM_NOTIFICATION_RELEASED: {
if (i == BTN_ID_CANCEL) {
WM_MESSAGE msg = { .MsgId = WM_MYMESSAGE, .hWinSrc = hWin };
WM_SendMessage(WM_HBKWIN, &msg);
}
}
}
}
default:
WM_DefaultProc(pMsg);
}
}

Display All

SEGGER - Florian · Mar 5th 2021, 9:52am

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

warlord · Mar 5th 2021, 10:20am

Florian,
How can user find out if there is a memory leak or not, with such normal behavior of emWin's memory management??

giusloq · Mar 5th 2021, 10:29am

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.

SEGGER - Florian · Mar 5th 2021, 11:44am

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

NumBytes = GUI_ALLOC_GetNumFreeBytes();
hWin = WM_CreateWindow(0, 0, 480, 272, WM_CF_SHOW, _cbWin, 0);
NumBytes = GUI_ALLOC_GetNumFreeBytes();
WM_DeleteWindow(hWin);
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

C Source Code

C Source Code

Share