Верхний (разумный) лимит на количество экземпляров пользовательского контроля

Question

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

Моим первым намерением было создать пользовательский элемент управления, представляющий элемент, и добавить их на панель во время выполнения. Это хороший подход? Иногда может быть более ста предметов. Я знаю, что существует максимальное количество элементов управления, которые вы теоретически можете использовать для формы, но это не моя главная задача. Моя забота в основном о производительности.

Другим подходом, о котором я думал, было создание списка и выполнение дополнительных действий в методе onPaint. Но это кажется немного нестабильным и слишком сложным для обслуживания.

Есть мысли?

---

EDIT:

Я протестировал подход usercontrol, добавив 200 пользовательских контролей в панель att form_Load и для фактического добавления требуется немало времени, но, похоже, никаких проблем с производительностью не возникает. Прокрутка работает нормально, и я сделал каждый пользовательский элемент управления сворачиваемым, и эта функциональность никоим образом не отстает, даже если на панели около сотни над сотней.

Но все же ... Я полностью здесь?

Answer 1

UserControls - очень «тяжелые» животные, как и любой экземпляр System.Windows.Forms.Control, поскольку каждый из них оборачивает фактическое базовое собственное окно Win32. Каждое окно должно управляться операционной системой, проверяться на попадание, отправляться сообщения рисования и т. Д.

Традиционным решением для этого сценария в Windows является «виртуализация» элемента управления. Вместо создания 200 пользовательских элементов управления следует поддерживать массив из 200 «объектов», представляющих каждый элемент. Создайте один «большой» элемент управления, представляющий все меню, добавьте к нему ScrollBar и переопределите OnPaint, рисуя только видимые элементы.

Это то, что делают нативные элементы управления старой школы, такие как ListBox и TreeView.

Теперь я верю, что Windows может немного вам здесь помочь, в зависимости от того, насколько вам нужно. Ключевое слово, которое вы ищете, является "нарисованным владельцем". Крики от другой ответ :

Подкласс ListBox. В ctor установите режим рисования на OwnerDrawVariable и переопределите OnDrawItem и OnMeasureItem.

Таким образом, встроенные элементы управления будут обрабатывать всю прокрутку и математику, необходимые для выяснения того, где вы находитесь в списке и с чего начать рисование.