Bom dia Rogerio.

Hmm... não sei. Por enquanto acho que ainda está na lista para revisão.

Ivan... Boa Noite...

Já temos uma atualização com essa correção?

Rogério Mauri

---

Combinado, passo para eles depois.

Legal que resolveu por aí.

Sim.. resolvido...

Mas, fica a sugestão para correção.

Rogério Mauri

---

Opa, entendi sim. Com o Clear você resolveu a situação?

Ivan... Achei...

No requery os grupos do ListView não são 'destruídos'....

Assim, na segunda chamada o ListView reaproveita os grupos já existentes ordenados de acordo com a sequência de construção da chamada anterior.

Por exemplo...

Na primeira chamada tenho as cidades de ARARAQUARA e BARRETOS...

- Os grupos são construídos na ordem, ficando assim:
    
     ARARAQUARA
        . Item 1
        . Item 2
     BARRETOS
        . Item 1
        . Item 2

Na segunda chamada (por isso o problema não aparecida na primeira carga) tenho, no novo BO carregado, as cidades de AMERICO DE CAMPOS, ARARAQUARA...

- Os grupos são então montados errados. Pela lógica, AMERICO DE CAMPOS vem antes de ARARAQUARA. No entanto, como ARARAQUARA já foi criada no Requery anterior, ela ficará presa na sequência (e BARRETOS agora passará a existir na coleção, sem uso... consumindo recursos). Não sendo destruídos os grupos na entrada do Requery (listView1.Groups.Clear()), os registros são posicionados com agrupamento desordenado, ficando assim:

    ARARAQUARA
       . Item 1
       . Item 2
       . Item 3
    AMERICO DE CAMPOS
       . Item 1
       . Item 2

Ficou claro ?

Rogério Mauri

---

Legal Rogerio.

Passo isto para a frente depois.

Abraços.

Ivan...

Fiz os testes retirando a barra, mas não deu certo... Continua apresentando problemas na ordenação, independente de configurados a ordenação por coluna no SFListView ou ordenação a partir da carga do BO (filldatatable).

Irei pesquisar mais, mas a situação é real.

Rogério Mauri

---

Ivan... Boa Tarde...

Acho que encontrei o ponto do problema.

No código fonte do componente SFListView, método CreateListViewItem encontrei o seguinte código:



Observe que o GroupHeaderText está sendo utilizado para compor a propriedade Name da coleção Groups do ListView.

No meu caso eu estou utilizando uma "/" para separar o nome da cidade do estado e, com certeza, essa "/" está provocando o problema, pois ela não está na sequência de replaces utilizados para limpar caracteres inválidos da variável groupName.

Aqui, já resolvi, mas sugiro adicionar ao código de replaces do groupName mais opções para limpar a cadeia de caracteres do GroupHeaderText.

Outra sugestão seria criar uma propriedade nova no controle SFListView para que o desenvolvedor decidisse pela construção do 'name' do group, deixando o GroupHeaderText livre para a propriedade Text. Assim, saberiamos que a propriedade 'name' não aceita espaços e outros caracteres inválidos.

Sugestão: "GroupHeaderName".

Se essa propriedade for deixada em branco, o componente assumiria para Name do group o que está no GroupHeaderText (Isso irá garantir a compatibilidade com versões anteriores do SF). Assim, propondo o novo código na classe ListView.vb, método CreateListViewItem:

Código em C#:

// Create a group name
groupName = rowEventArgs.GroupHeaderName.Trim().Length != 0 ? rowEventArgs.GroupHeaderName.Trim() : rowEventArgs.GroupHeaderText.Replace......;


Abraços...




Rogério Mauri

---

Boa Noite Rogerio.

Você já experimentou já ordenar o seu BO no seu Fill method? No seu SELECT, já poderia usar um ORDER BY e ele já retornaria ordenado por cidade, seja qual for a data que estiver procurando. Assim não precisa nem usar o Sort no BO. Para dar uma opinião melhor, teria que ver seu código, mas quem sabe se fizer o que falei já resolve seu problema.

Abraços.