Hello!

Using VS.NET 2003, C++ .NET Form project. I'm beginner to .NET and Win
programming so even if my question is stupid please bear with it.

I'm having problems with starting a program minimized. In theory it's done
easily by setting the WindowState property of the main form to 'Minimized' in
the designer. But that's not all.

Take a very simple VS.NET 2003 C++ project of 1 Form and a few other
controls (say, 1 ContextMenu, 2 MenuItems, 1 NotifyIcon and 1 ICOn resource
file), NO manually added code. When run normally (not minimized), this takes
9-10M RAM (seen in Task Explorer, has ~8M working set in a more thorough
process explorer). A minimize reduces the RAM usage to ~1M. Another restore,
and it uses 2-3M again. Yet another minimize and a footprint of 0.8-0.9M is
reached. No, it doesn't go any further, unfortunately. And there's no
significant difference between a 'release' and a 'debug' build, both start
with huge footprints.

My problem is this: when starting the application minimized, it takes up
9-10M, until I restore/minimize it a few times. So starting it minimized
doesn't reduce the memory usage, but showing the window and minimizing it
afterwards does. Putting the 'WindowState=Minimized' command in the Load or
focus-related events in order to have it immediately minimized doesn't help
(application starts minimized, memory usage remains). Initiating garbage
collection is without effect.

Any ideas, how I could mimic the effects of a 'minimize' without having to
actually display the window? Is there any way to tell the framework
explicitly to drop unneeded memory regions?

Working set isn't the same as memory usage. I suggest you read the
following.

http://getdotnetco.web101.discountasp.net/GdncStore/free/Articles/The%20Memory%20Mystery.htm


Mattias

You should follow Mattias Sjögren's suggestion and read up on memory usage in
..net.  The general conclusion you should draw is that .net will take care of
memory business in its own time, and you shouldn't worry about it.

However, regarding your question:

The answer is to call kernel32 api SetProcessWorkingSetSize() with -1
parameters and to iterate about three calls to GC.Collect() and
GC.WaitForPendingFinalizers().

I have used these operations to troubleshoot.  A couple of years ago, they
helped me solve a memory leak problem owing to my failure to dispose a
menuitem.  Today there are better tools for chasing memory leaks.  I do not
use these procedures during ordinary operations, and you shouldn't either. 
You should not do these operations to reduce some reported memory numbers
absent a problem.  You should not do these operations to reduce some reported
memory numbers to satisfy others who are complaining about your app's memory
footprint - explain how it works instead.

On the other hand, it is always a good thing to prove that you don't have
memory leaks before deployment.

Thank you for your kind help. I think I understand the situation now. Still,
it's good to know how to force the trimming of the working set, although I
won't be using it.

ProcessStartInfo.WorkingDirectory and Mapped Network Drives
How to use VS2005 Documentation
Threading Question.
Could not find a part of the path
is .NET using COM/COM+ technologies?