Вопрос

Что могло бы привести к свертыванию TreeView, кроме вызова .Метода Collapse() в TreeNode или .Метода CollapseAll() TreeView?

В приложении, которое я разрабатываю, TreeView просто не будет вести себя должным образом.TreeView поддерживает только два уровня.При выборе дочернего элемента родительского узла все остальные узлы немедленно сворачиваются.Однако в моем коде нет никаких .Вызовов метода Collapse() или .CollapseAll() вообще!

Все свойства TreeView остаются по умолчанию, за исключением .Свойству LabelEdit, для которого установлено значение true .TreeView имеет некоторый код, связанный с событием AfterLabelEdit для простой процедуры проверки / MessageBox .

Я пытался:

  • Подключение события BeforeCollapse для просмотра дерева и поднятие флага e.cancelAction.

  • Вручную разворачивая все узлы в AfterSelect в TreeView событие.(Это прекрасно работает как эксперимент, но я не собираюсь запрещать сворачивание узла
    в целом!)

Во многих точках кода я перебираю TreeView, узел за узлом, чтобы проверить свойства.Однако никаких добавлений или удалений узлов не происходит.Единственными свойствами TreeNode, которые изменяются по мере выбора пользователем, являются .ImageIndex и .SelectedImageIndex .

Кроме двух приведенных выше решений, я не имею ни малейшего представления о том, что может быть причиной этой ошибки.Даже если никакие решения не могут быть реализованы, может быть, у кого-нибудь есть идея о том, как правильно остановить коллапс?(Я попытался установить точку останова в событии BeforeCollapse, но оно не срабатывает, если пользователь явно не сворачивает узел с помощью мыши или клавиатуры.)


Обновить:

Проблема связана с изменением .Свойство SelectedImageIndex для любого TreeNode.Изменение этого свойства приводит к свертыванию всех остальных узлов.

Я попытался окружить .Код модификации свойства SelectedImageIndex .Вызовы BeginUpdate() и .EndUpdate() безрезультатными.

Как этого можно избежать?

Это было полезно?

Решение

Это побочный эффект того, как работает встроенная Windows в Windows.Многие параметры окна задаются флагами стиля в вызове CreateWindowEx().Базовые вещи, например, как выглядит граница на форме.Какой вид должен иметь ListView.Должен ли TreeView отображать флажки.

Эти стили отображаются как свойства элемента управления.Но есть одна проблема.Изменение такого свойства требует воссоздания окна с нуля, чтобы в вызове CreateWindowEx() можно было указать флаги нового стиля.Это имеет побочные эффекты, окно полностью воссоздается заново, поэтому оно теряет все предыдущее состояние.

Windows Forms проделывает довольно хорошую работу по приданию этому виду плавности, восстанавливая предыдущее состояние после повторного создания окна.Но это есть утечки тут и там.И несколько откровенных ошибок.Одна из утечек в TreeView - это точное состояние того, какие узлы свернуты, а какие нет.Отслеживать это просто непрактично.

Диагностируйте это, поместив свойство Handle TreeView в окно просмотра.Если вы видите, что это изменилось, значит, вы нашли нужное свойство.Доступен список флагов стиля здесь, вероятно, вы можете сопоставить их имена с соответствующим свойством.

Возможно, очевидно, что для решения этой проблемы нет отличного решения, кроме как избежать изменения этого свойства.Проблема, подобная этой, - это то, что породило WPF.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top