Очистка элементов управления FlowLayoutPanel, не вызывающих деструкторов?

Извините, если мне не хватает чего-то очевидного, но я пытаюсь очистить элементы управления (серию пользовательских элементов управления) от FlowLayoutPanel - (имя_панели) .Controls.Clear() ;. К сожалению, это, похоже, не вызывает деструкторы для объектов на панели - столбец «Пользовательские объекты» в диспетчере задач просто продолжает подниматься вверх и вверх, пока он не достигнет 10 000 и выбрасывает исключение.Очистка элементов управления FlowLayoutPanel, не вызывающих деструкторов?

Кто-нибудь знает, что мне здесь не хватает?

источник

2009-09-04 eftpotrm

Деструктор вызывается GC. – adatapost

Спасибо, к сожалению, никаких свидетельств этого никогда не происходит. – eftpotrm

У меня была такая же проблема с очисткой пучка элементов управления ZedGraph из панели flowlayout. В итоге я получил «дескриптор создания ошибок», так как он ударил 10 000 ручек USER. –

не решение, а обходной путь - объекты, кажется, будут уничтожены это (грубо, из памяти) Код:

while(FlowLayoutPanel.Controls.Count > 0) 
    FlowLayoutPanel.Controls.Remove(0);

источник

2009-09-09 10:39:03 eftpotrm

Небольшая вариация: while (FlowLayoutPanel.Controls.Count> 0) { FlowLayoutPanel.Controls.Clear(); } –

Хорошая точка, это было бы быстрее, не так ли :) – eftpotrm

Обходной путь все еще сохранял количество обработчиков пользователей, увеличивающихся для меня (использование управления Zedgraph), однако, если я просто вручную располагаю элемент управления после его удаления из панели flowlayout, это исправил его на 100% для меня (поддерживал постоянный счетчик пользователей) –

У .NET нет концепции деструкторов. У .NET есть что-то, называемое «финализаторы», которые выглядят синтаксически как деструкторы в C#. Для получения дополнительной информации ознакомьтесь с замечательной книгой Джеффа Рихтера о том, как работает CLR - CLR via C#.

Возможно, вам захочется, чтобы объекты реализовали шаблон IDisposable, а затем вызывается их метод Dispose(), когда вы закончите с ними.

источник

2009-09-04 11:30:53

Извините, мозг не в снаряжении на языке, я имел в виду финализаторы, которых я обещаю :-) В любом случае, это не называется. Пользовательский элемент управления реализует IDisposable, который делает все, что он должен. Я попытался с финализатором на случай, также уничтожив детей. Я попытался явно вызвать сборщик мусора - во всех случаях пользовательские объекты просто маршируют до 10 тыс. И вызывают исключение. – eftpotrm

Какое исключение? Из того, что вы говорите, я не думаю, что вы полностью понимаете механизмы финализаторов и интерфейс IDisposable ... –

Очень возможно - ошибка создания дескриптора окна. – eftpotrm

Попробуйте использовать профайлер памяти, (например ants), это будет скажите, что удерживает контроль. Попытка 2-го угадать, что этот тип проблемы очень тяжелый.

Red-gate дает 14-дневный хвост, который должен быть более чем достаточно, чтобы решить эту проблему и решить, дает ли профилировщик памяти долгосрочную ценность.

Есть много других профайлеры памяти на рынке (например, .NET Memory Profiler), большинство из них имеют бесплатные пробные версии, однако я обнаружил, что Red-Gate инструментов просты в использовании, поэтому, как правило, пытаются их первыми.

источник

2009-09-24 17:22:48

Обходное решение eftpotrm выше, тем не менее, продолжает увеличивать количество обработчиков пользователей, если вы просто вручную удалили после удаления элемента управления, что зафиксировало его на 100% для меня.

while (myFlowLayoutPanel.Controls.Count > 0) 
{ 
    var controltoremove = myFlowLayoutPanel.Controls[0]; 
    myFlowLayoutPanel.Controls.Remove(controltoremove); 
    controltoremove.Dispose(); 
}

источник

2012-08-01 15:59:22

Очистка элементов управления FlowLayoutPanel, не вызывающих деструкторов?

ответ

Смежные вопросы