Bueno Antonio,
I finally have an answer for why I need to use ExitProcess() instead of
IupDestroy() for the code listed below. It has to do with whether a modeless
dialog box or modal subwindow is opened. For a modeless dialog box, Windows
specifies that you call DestroyWindow(), PostQuitMessage(), and ExitProcess(),
but for a model dialog box, if we use DestroyWindow() to
destroy the dialogbox, PostQuitMessage() is never received so the message loop
remains in memory, causing the "memory leak" that I can see when you run the
code below. In those cases you should use EndDialog() and then ExitProcess().
Yes, DestroyWindow() will work in place of EndDialog() but I'm not sure it is
technically the proper API to use per Microsoft but it works just fine with
IUP.
Best Regards,
Andrew
On 1/24/2017 at 4:16 PM, Andrew Robinson <arobinso...@cox.net> wrote:
Hi,
The listed code was copied from the IUP notepad tutorial, just to be safe. It
creates a small memory leak but the real problem is that after closing out the
program, a zombie of the program is still left behind that doesn't exist when
you don't use IupFileDlg().
When a window is destroyed and there are attached processes that have not been
terminated, Microsoft will destroy the window but keep the program running.
Iup clearly doesn't kill any open processes on exit, but if I end the IUP
program with ExitProcess() instead of IupClose(), it will terminate
completely. So whatever processes are opened but not closed, they are being
opened when IupFileDlg() is called but not killed when IupDestroy() or
IupClose() is called. The common file/item dialog requires a Release(), but
that is up to Iup to perform, not the programmer, and it seems that should be
performed within IupDestroy().
So what are you asking me to troubleshoot here? The Microsoft component or the
Iup component? Or does citing the fact that using ExitProcess() works where
IupClose() does not, enough to resolve this issue?
Andrew
On 1/24/2017 at 10:37 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
Hi,
Are you using Visual Studio? There is a free tool called Visual Leak
Detector (https://vld.codeplex.com/) that is very useful for detecting leaks.
And it is much more precise than Task Manager regarding to leaks in the
application.
I said that because IupFileDlg uses a native dialog from Windows API that
loads a lot of stuff. Maybe that stuff is cached in the system memory for
future reuse.
Best,
Scuri
On Tue, Jan 24, 2017 at 3:08 PM, Andrew Robinson <arobinso...@cox.net> wrote:
Hello,
I am running an app with the following code:
int fnSrcFile_cb(void) {
Ihandle *filedlg = IupFileDlg();
IupSetAttribute(filedlg, "DIALOGTYPE", "OPEN");
IupSetAttribute(filedlg, "EXTFILTER", "Text Files|*.txt|All Files|*.*|");
IupPopup(filedlg, IUP_CENTER, IUP_CENTER);
if (IupGetInt(filedlg, "STATUS") != -1) {
char* filename = IupGetAttribute(filedlg, "VALUE");
IupSetStrAttribute(txt1,'VALUE',filename) }
IupDestroy(filedlg);
return IUP_DEFAULT }
With Task Manager open, the app starts out taking up 5K of memory, but as soon
as I click on the control button that calls the code above, it jumps to ~15k,
even if all I do is open the dialog and click on cancel. If I keep on opening
and then canceling the file dialog, the memory slowly creeps up in size.
Closing the app leaves a ~12k stub in memory, indicating it wasn't actually
destroyed. If I do not call the file dialog, the app opens and closes, leaving
nothing behind in memory.
I am using Windows7 and the latest version of IUP (3.21).
Thanks,
Andrew
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
