1

i'm making a small c# form app and i copied a piece of code that let me resize a borderless form from the bottom right of the form:

protected override void WndProc(ref Message m)
        {
            if (m.Msg == 0x84)
            {
                Point pos = new Point(m.LParam.ToInt32());
                pos = this.PointToClient(pos);
                if (pos.Y < cCaption)
                {
                    m.Result = (IntPtr)2;
                    return;
                }

                if (pos.X >= this.ClientSize.Width - cGrip && pos.Y >= this.ClientSize.Height - cGrip)
                {
                    m.Result = (IntPtr)17;
                    return;
                }
            }
            base.WndProc(ref m);
        }

The problem is that i wanna make the program as light as possible but every time i resize the form and therefore call this piece of code, the application increases the ram usage.

I don't really understand how WndProc() works and i thank you a lot if you could explain me why the ram usage increases.

Steve
  • 47
  • 6
  • 2
    This is taken from [here](https://stackoverflow.com/a/2575452/7444103), you should mention that and it's not related to increased resources usage. Something else happens. Are you maybe drawing something, images? Do you have Custom Controls with custom rendering? Other similar? – Jimi Jan 26 '23 at 15:44
  • *Every* time? If you do this 20 times in a row, or wait a minute before another batch of resizes, does the memory usage keep going up? As .NET uses dynamic allocation and garbage collection, it's not unusual for programs to increase their memory consumption for a while before reaching a steady state, but that's different from the kind of unbounded increase that would indicate a memory leak. This code should not leak, so another possibility if you do notice an unbounded increase is that some global hook is mucking things up -- which would mean you'd see this on *every* application. – Jeroen Mostert Jan 26 '23 at 15:46
  • 1
    you should use a memory profiler to see what is actually being retained – Daniel A. White Jan 26 '23 at 15:46
  • There is no obvious reason why the posted example code would leak memory. Typical reasons is that you leak event-handlers, or use some type of native object that needs explicit destruction. I would suspect your leak is in some rendering code, and resizing is just a way to trigger frequent re-renderings. You should really use a memory profiler. – JonasH Jan 26 '23 at 15:50
  • @Jimi When i resize the window i don't draw nothing but i have some controls anchored to the window such as: RichTextBox, 4 Pictureboxes with images that work as buttons (Close, FullScreen, Minimize, Settings). Maybe it redraws those contorls? But why the memory doesn't clean up with the GC? – Steve Jan 27 '23 at 16:11
  • @JeroenMostert The memory increases for some megabytes (8 to 15) and then it stops. Yeah i know some megabytes are nothing but i really want to make this app as light as possible, and more, i want to know what causes the memory to go up. – Steve Jan 27 '23 at 16:15
  • @DanielA.White should i share the memory report? Plus, running with the memory profiler on the ram allocation doesn't increase that much. Normal run = 8 to 15 Memory profiler = 17 to 19 – Steve Jan 27 '23 at 16:17
  • 1
    If the *memory increases for some megabytes (8 to 15) and then it stops*, the there's no leak. A leak (usually determined by allocations generated by graphics rendering that are never released) cause a constant increase in memory usage that is never released, even when getting near the 2GB *barrier* (because of unmanaged resources that the GC cannot release) -- The first interaction with the application causes some caching, which helps with the overall performance. A few MB that are never released (because there's no need or memory pressure, or no means to do it) – Jimi Jan 27 '23 at 16:25
  • 1
    What you observe is pretty much normal behavior for a managed application. If you're concerned about making the app as light as absolutely possible, to the point where you're concerned about a one-time allocation of a memory segment (because the CLR allocated memory in large blocks to carve smaller ones from, to increase efficiency) it's honestly more realistic to not use .NET at all -- of course you do pay a cost for that in terms of development speed. – Jeroen Mostert Jan 28 '23 at 13:03
  • @JeroenMostert Yeah i've thought of that thanks. Do you know by any chance what should i use instead of .NET? – Steve Jan 30 '23 at 09:21
  • 1
    I haven't done serious GUI work on the desktop in quite a while. Of course it all starts with good old-fashioned Win32 coding with C++ with MFC/ATL, which VS has full designer support for, but if you're looking for something modern and sexy you might also take a look at [Rust](https://blogs.windows.com/windowsdeveloper/2021/05/06/announcing-rust-for-windows-v0-9/) (disclaimer: no personal experience). With either language you remain in control of memory allocation, if you feel the need to care. – Jeroen Mostert Jan 30 '23 at 09:30

0 Answers0