Pergunta

O que poderia causar uma TreeView ao colapso, que não seja uma chamada para o método .Collapse () em um TreeNode ou o .CollapseAll () método do TreeView?

Em um aplicativo que estou desenvolvendo, TreeView irá simplesmente não se comportam corretamente. O TreeView mantém apenas dois níveis. Ao selecionar uma criança de um nó pai, todos os outros nós em colapso imediatamente. No entanto, não há .Collapse () ou .CollapseAll () chamadas de método no meu código que seja!

Todas as propriedades dos TreeView são deixados em seus padrões, exceto a propriedade .LabelEdit, que é definido como verdadeiro. O TreeView tem algum código associado dentro do evento AfterLabelEdit para uma validação simples rotina / MessageBox.

Eu tentei:

  • Hooking o BeforeCollapse caso de o TreeView e elevar o e.CancelAction bandeira.

  • manualmente expandir todos os nós dentro AfterSelect do TreeView evento. (Esta multa funciona como um experimentar, mas eu não pretendo nó disallow colapso
    completamente!)

Em muitos pontos dentro do código, eu sou a iteração através da TreeView, nó por nó, para verificar as propriedades. No entanto, não há adições ou deleções de nodos ocorrer. As únicas propriedades TreeNode que são modificados como o utilizador faz selecções são .ImageIndex e .SelectedImageIndex.

Além das duas soluções acima, eu não tenho nenhuma pista sobre o que pode estar causando esse erro. Mesmo se nenhuma solução pode ser realizado, poder Alguém tem uma idéia sobre a maneira correta de ir sobre prendendo o colapso? (Eu tentei definir um ponto de interrupção dentro do evento BeforeCollapse, mas não disparado a menos que o usuário entra em colapso explicitamente o nó através do mouse ou teclado.)


UPDATE:

O problema é devido a chaging a propriedade .SelectedImageIndex em qualquer TreeNode. A alteração dessa propriedade faz com que todos os outros nós ao colapso.

Eu tentei em torno do código de modificação de propriedade .SelectedImageIndex com .BeginUpdate () e .EndUpdate () chamadas sem sucesso.

Como isso pode ser evitado?

Foi útil?

Solução

Este é um efeito colateral da forma como janelas nativas funcionam no Windows. Muitas das opções de janela são especificados por sinalizadores de estilo na chamada CreateWindowEx (). coisas básicas, como o que os olhares de fronteira como em um formulário. Que tipo de vista de um ListView deve ter. Se um TreeView deve exibir caixas de seleção.

Estes estilos são expostos como propriedades em um controle. Mas há um problema. Alterar tal propriedade um requer a janela para ser recriado a partir do zero para que os novos sinalizadores de estilo pode ser especificado na chamada CreateWindowEx (). Isso tem efeitos colaterais, a janela fica completamente recriado por isso perde todo o estado anterior.

Windows Forms faz um trabalho muito bom de fazer essa aparência suave e restaurar o estado anterior após a recriação da janela. Mas há vazamentos aqui e ali. E alguns bugs definitivas. Um vazamento no TreeView é o estado exacto de quais nós são recolhidos e quais não são. Manter o controle de este não é apenas prática.

Diagnosticar isso colocando a propriedade Handle do TreeView em uma janela do relógio. Se você vê-lo mudar, você encontrou o imóvel. A lista de sinalizadores de estilo está disponível aqui, você provavelmente pode mapear seus nomes à sua propriedade correspondente.

Talvez seja claro que não há nenhuma grande solução para este problema, que não seja evitando mudando essa propriedade. Problemas como este é o que gerou WPF.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top