Bob,
From what I see in the code you posted I must say you don't do anything =
wrong and this is exactly the way to update the UI from a worker thread. =
Regarding the memory leaks there might be problems some where in the =
code, but from what I can see here the GC should take care of the memory =
heap and should keep everything under control. Just keep in mind that =
the GC kick off only if there is need for that; until then the memory =
consumption will increase.
--=20
Stoitcho Goutsev (100)
[quoted text, click to view] "Bob" <nospam@nospam.com.au> wrote in message =
news:un2TSXgiGHA.4304@TK2MSFTNGP03.phx.gbl...
Hi all,=20
I seem to be chewing up memory at a nasty rate when my app runs.
It has a polling loop and not surprisingly this is the part that keeps =
doing it.
I think I've located the line that is my main offender and its when I =
marshal to get back onto the GUI thread so I can update my controls.
private void KPI_ScreenUpdate(KPI KPIType)
{
if (this.InvokeRequired)
this.Invoke(new KPI_ScreenUpdateDelegate(KPI_ScreenUpdate), new =
object[] { KPIType });
else
{
DPL_Units_Through.Value =3D myKPI_Shift.Units_Through;
DPL_Shift_Time.Value =3D tmpElapsed.ToString();
DPL_Elapsed_Setup_Time.Value =3D tmpSetupElapsed.ToString();
}
Now what I've noticed is that anytime I create an object using 'NEW' =
keyword in my loop (called every n seconds) .. I can watch the memory =
usage of my app go up and never down.
So mostly I've been ensuring that I never create an object in one of =
these loops.
But I thought that the garbage collector would deal with these objects =
once they go out of scope .. and I dont know any other way except the =
above snippet to ensure I dont cross thread for the control update.
Will the garbage collector keep my memory under control if I use it =
implicitly ??? or am I doing something fundementally flawed when =
marshalling threads ?