Joe
Thu Sep 11 01:04:22 CDT 2003
Are you using any UpDownControls? There's a known bug with those -- in
general, a form that contains an UpDownControl will never get
garbage-collected. I saw another thread in this NG within the past two
or three days that discussed this and mentioned a workaround.
Tappy Tibbons wrote:
> Both... Also controls from 2 different 3rd parties. The form is the main
> screen for some heavy duty power user CSR's.
>
> That's what makes it so difficult to troubleshoot or to even try to pinpoint
> where the problem could be....
>
>
>
> "Steve Austin" <steve.austin@capecanaveral.com> wrote in message
> news:lPGcnbmN093P2sKiU-KYvg@giganews.com...
>
>>Just a quick question - are you using standard controls, or custom ones?
>>
>>"Tappy Tibbons" <tappytibbons@sbcglobal.net> wrote in message
>>news:%23MSby45dDHA.3260@TK2MSFTNGP09.phx.gbl...
>>
>>>Thanks for the tip, and the URL. I will try running it. I have never
>>
> used
>
>>>one of these. Is it pretty self explanatory, or am I looking at a lot of
>>>work to get it installed, running, and learning it's operation?
>>>
>>>We are not really doing any menuing at all in this app.
>>>
>>>Any other ideas?
>>>
>>>
>>>"Stuart Wells" <stuart.wells@focus-solutions.co.uk> wrote in message
>>>news:024c01c37771$411b64f0$a001280a@phx.gbl...
>>>
>>>>Sounds like you are bleeding memory - not necessarily of
>>>>your own making.
>>>>
>>>>I use the following tool to detect this sort of behaviour:
>>>>
http://www.scitech.se/memprofiler/Default.htm
>>>>
>>>>In my experience I have found that any classes I have
>>>>written clean up perfectly (most of the time ;-) but some
>>>>standard components do not.
>>>>
>>>>The most frequent offender is the menuitem component -
>>>>especially if you are using dynamic menuitem creation.
>>>>
>>>>I believe there is a bug in the Framework which causes
>>>>duplicate (cloned) menuitems to be created but not
>>>>destroyed when menuitem merges take place (such as
>>>>MDIChild to parent menu merges). These I cannot cure
>>>>(unless someone knows how?).
>>>>
>>>>Try extending the dispose method on the form to explicitly
>>>>unregister ALL the menuitem event handlers - I know this
>>>>seems a lot of work but it stopped exactly what you are
>>>>explaining in my application.
>>>>
>>>>Stuart
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>We have rolled out an app, and are experiencing complete
>>>>
>>>>application and
>>>>
>>>>>system slowdown as users open and close windows forms in
>>>>
>>>>our app throughout
>>>>
>>>>>the day.
>>>>>
>>>>>It usually happens about 50 or so form opening/closing
>>>>
>>>>cycles.
>>>>
>>>>>If the user notices the app is slowing down, and they
>>>>
>>>>exit the app then go
>>>>
>>>>>back in, it works fine for another 50 or so open/closes.
>>>>>
>>>>>If they keep pushing it, and go another 20-30 times, it
>>>>
>>>>will eventually be
>>>>
>>>>>so slow the form takes 2-3 minutes to redraw, and will
>>>>
>>>>eventually lock their
>>>>
>>>>>PC, forcing a reboot.
>>>>>
>>>>>The forms do have quite a few controls on them. They do
>>>>
>>>>talk to a database,
>>>>
>>>>>but not using bound forms, and the data access is pretty
>>>>
>>>>small.
>>>>
>>>>>We have tried setting all objects to nothing at the end
>>>>
>>>>of all procedures,
>>>>
>>>>>doing GC.Collect, other things, but can't quite nail it
>>>>
>>>>down...
>>>>
>>>>>The client machines are all WinXP SP1, P4 2.XGhz, 512MB
>>>>
>>>>RAM or better.
>>>>
>>>>>Version 1.0 of the framework, VS2002.
>>>>>
>>>>>Any ideas on troubleshooting this? Is there a specific
>>>>
>>>>memory counter
>>>>
>>>>>somewhere I can monitor or display on the form, so I can
>>>>
>>>>see if it goes
>>>>
>>>>>down? The task manager memory for the app grows and
>>>>
>>>>grows, but I understand
>>>>
>>>>>that may not be a real accurate gauge of memory usage.
>>>>>
>>>>>Thanks!