Pregunta

¿Qué causaría un método TreeView a colapsar, aparte de una llamada a la .Collapse () en un método .CollapseAll () del TreeView o NodoArbol?

En una aplicación que estoy desarrollando, TreeView simplemente no se comportan adecuadamente. El TreeView mantiene sólo dos niveles. Al seleccionar un hijo de un nodo padre, todos los demás nodos colapsan de inmediato. Sin embargo, no hay .Collapse () o .CollapseAll () método llama en mi código en absoluto!

Todas las propiedades de la TreeView se dejan a sus valores predeterminados excepto la propiedad .LabelEdit, que se establece en true. El TreeView tiene un código asociado en el caso AfterLabelEdit por una simple rutina de validación / cuadro de mensaje.

He tratado:

  • El enganchar el caso de BeforeCollapse TreeView y el aumento de la bandera e.CancelAction.

  • expandir manualmente todos los nodos AfterSelect dentro del TreeView evento. (Esto funciona bien como una experimento, pero no tengo la intención de no permitir el nodo colapso
    en conjunto!)

En muchos puntos dentro del código, estoy iteración a través del TreeView, nodo por nodo, para comprobar las propiedades. Sin embargo, no se producen adiciones o deleciones de nodos. Las únicas propiedades TreeNode que son modificados como el usuario realiza selecciones son .ImageIndex y .SelectedImageIndex.

Aparte de las dos soluciones anteriores, no tengo ninguna pista en cuanto a lo que puede ser la causa de este error. Incluso si no hay soluciones se pueden realizar, podría alguien tiene una idea acerca de la forma correcta de ir sobre la captura del colapso? (He intentado fijar un punto de interrupción dentro del evento BeforeCollapse, pero no activado a menos que el usuario se derrumba explícitamente el nodo a través del ratón o el teclado.)


ACTUALIZACIÓN:

El problema se debe a la propiedad chaging .SelectedImageIndex en cualquier TreeNode. El cambio de esta propiedad hace que todos los demás nodos se colapse.

He intentado que rodea el código de modificación de la propiedad .SelectedImageIndex con .BeginUpdate () y .EndUpdate () llama en vano.

¿Cómo se puede evitar esto?

¿Fue útil?

Solución

Este es un efecto secundario de la forma ventanas nativas funcionan en Windows. Muchas de las opciones de la ventana se especifica por indicadores de estilo en la llamada CreateWindowEx (). cosas básicas, como lo que la frontera se ve como en un formulario. Ver qué tipo de un ListView debe tener. Ya sea un TreeView debe mostrar casillas de verificación.

Estos estilos se exponen como propiedades en un control. Pero hay un problema. Cambiar una propiedad tal requiere la ventana para volver a crear desde cero para que los nuevos indicadores de estilo se pueden especificar en el () llamada CreateWindowEx. Eso no tiene efectos secundarios, la ventana se vuelve a crear por completo por lo que pierde todo el estado anterior.

Windows Forms hace un muy buen trabajo de hacer esta mirada suave, restaurando el estado anterior después de volver a crear la ventana. Pero hay fugas de aquí y allá. Y algunos errores absolutos. Una fuga en TreeView es el estado exacto de la cual los nodos se colapsaron y que no lo son. Hacer un seguimiento de esto es simplemente no es práctico.

Diagnosticar esto poniendo la propiedad Handle del TreeView en una ventana de inspección. Si ves que cambia, que ha encontrado la propiedad. La lista de indicadores de estilo está disponible aquí, es probable que pueda mapear sus nombres a su propiedad correspondiente.

Tal vez está claro que no hay una gran solución para este problema, aparte de evitar el cambio de esa propiedad. El problema de este tipo es lo engendró WPF.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top