WM_COMPACTING

[Troy King]

A couple of questions:

One, does the PB compiler build in a reaction to WM_COMPACTING messages? I can't seem to get it to "automatically" give up any memory in response to one.

Two, what should I do in response to a WM_COMPACTING myself, other than RESETting any dynamic strings and ERASEing any arrays that I can spare?

-------------
Troy King
[email protected]

[Lance Edmonds]

Thats about the most you can do yourself, except perhaps release those thousands of GDI objects and DLL's your app is hogging unnecessarily!

There is no possible way for PB/DLL to handle WM_COMPACTING "automatically" as it could not presume to know what data your app may or may not need.

If your app is not abel to release memory or resources back to the heap, then not worry about it too much - there is little you can do to tame the other apps that are running and occupying most available memory...

Seriously though... are you handling this message for a particular reason, or is this an effort to make your app continue to run while Windows burns? (Ok, I'm being cynical!)

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Troy King]

Thanks for the help. I just good-old didn't know about whether the DDT runtime had anything internally that it could release in response to WM_COMPACTING.

Seriously though... are you handling this message for a particular reason, or is this an effort to make your app continue to run while Windows burns? (Ok, I'm being cynical!)

You know, just trying to be a good "Windows Citizen". The tiny little executables make *me* look good and obviously are the result of excellent work by The Bob and other compiler developers (not that my clients know that) and while I try to release everything I'm not using, I thought I'd do a good slash-and-burn in response to a WM_COMPACTING.

My app currently runs about 1020K with only a hidden dialog and tray icon and tray icon menu, and jumps to 1380K after I load a DDT-based dialog in response to a menu click. Even though I ERASE and RESET all globals the dialog used after unloading it and do DIALOG ENDs on the dialog and its child dialogs, the memory stays at 1380K. That's not necessarily related to my initial question, but I guess in a way it is... Is there any way to get that memory "back"? Most likely I'm doing something dumb that keeps it in use. I was thinking it could be DLLs called by the DDT runtime that aren't loaded before I call DDT, but stay loaded thereafter. I didn't think DDT called anything other than the standard USER32, KERNEL32, and GDI32, but I really don't know. Thus, my original question . Thanks again .

------------------
Troy King
[email protected]

[Lance Edmonds]

If you are using Win2K or NT, then the Task Manager is able to produce more granular results then the older Win9x resource meter could produce. For example, I can see the actual, peak and VM memory consumption with Win2k's TM.

From your description that the extra couple of hundred Kb is probably coming from a resource file in the form of a binary (or other) resource. If so, then in a tight squeeze Windows will probably release the resource from memory... resources are generally discardable, but only in a tight squeeze.

Of cource, being able to see your code will make it easier to advise you, but... my feeling is that you are worrying unnecessarily, especially givent hat your app has very low memory demands in general.

If you run your app through a tool like MEMCHECK 5 or BOUNDSCHECKER, then you can check for resource leaks, but you have to be wary of these tools - they report all sort of things that are not "real" errors.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Troy King]

Thanks again, Lance. You're probably right. There are only three icons in the resource file, but I do have 65 strings in it, and every string in the app comes from the resource file. The only resource dialog in the app is an empty dialog that's never visible (it's an empty window to house a timer proc, app-wide callbacks, and an always-loaded hWnd at which to point everything that needs one), and a resource menu.

I didn't mean to sound as though I were complaining! I was just trying to understand more of what DDT was calling since all the visible dialogs are DDT plus one titlebar icon from the resource file. I do use about 12 of the columns in the NT/W2K task manager, but I haven't run a spy yet to see if I'm unintentionally loading any DLLs (to me sometimes they're just random functions that come from the declare file, ya know *grin*). I'd hate to burden you with my code since you have so much else to do (plus, I'm ashamed of my own code, besides which half of it was stolen from these very forums). I probably sounded like I was saying "DDT is wasting my memory", but that's not what I meant at all, and I apologize. I'm just trying to learn more about what I can do in my own code to make as small and system-friendly an app as possible. I'm not nearly the artist that most of the forum regulars here are, and I'm trying to learn more. Thanks again for your suggestions, and I think I'll quit bugging you and load a spy utility now The app has grown to 1.6 to 2M of memory usage now, so I need to reel it in. It will be run as an always-on-in-the-tray app, and I need to shrink it.

------------------
Troy King
[email protected]