a) Correção: Se limpar o TopMost não altera o comportamento da busca (desconsidera index = 0), então obrigatoriamente ele deverá ser configurado; caso contrário teremos a falha em tempo de execução caso o desenvolvedor limpe os parâmetros na aba General esperando o resultado que eu mesmo imaginei.
b) Sugestão: Ajustar o controle para interpretar que ausência do parâmetro TopMost indica que o filtro sempre deverá ser configurado com o valor do SelectedValue, independente do seu index.
Recomendo adotar a sugestão, pois ampliaria o poder do BrowseDialog como ferramenta de seleção de registros e pelo que analisei no código da classe não será difícil fazer esse ajuste. Inclusive, o entendimento da lógica na aba General, nesse caso, estaria mais consistente. Rogério Mauri
Depois eu vou traduzir sua mensagem e enviar para eles, mas eu sinceramente acho que esta é a funcionalidade esperada para o Combobox. Nenhum campo deveria ser obrigatório para preenchimento, é para isto que há o Searching evento para se manipular sua procura da maneira que for necessária.
Mas vou passar isto para eles.
Permanecendo então a funcionalidade atual, o TopMost sempre será obrigatório. No entanto, nem precisa ter o campo TopMostValue (valor intrínseco), apenas o TopMostText (para poder colocar o texto personalizado). Afinal, o seu 'value' não é considerado.
Com isso o código do componente precisará ser reavaliado.
Rogério Mauri
Esqueci de algo importante.
Obrigado pelo acompanhamento e suporte. Rogério Mauri
Observe o descritivo do Help sobre o controle, especificamente quanto a utilização do TopMost.
Na prática, condição para criar o "None" não é possível. Sempre da "All", independente do que você coloque no par Text/Value.
Let me jump in here because I have had a conversation with Ivan about this. This is not a bug and works as it is intended to work. If you wish to override the TopMost logic in the browse dialog, then your ONLY option is to handle the Searching event of the browse dialog and then implement your logic to counteract the default behavior. This is a prime example of why this event was created. This is not something that is going to change within the framework since doing what you are asking would actually break every other SF user out there and would not be backward compatible. Even if we were to make a change, this would not be implemented for another version or two. And since the preferred method to handle this is going to be through the Searching event, then you already have a solution to do exactly what you would like.
I thought I better jump in here because you are pressing for an answer that you are not likely to get and I wanted you to be able to spend your time working through a solution using an existing mechanism that exists within the framework.
Então, para finalizar este diálogo, poderia me dar um exemplo funcional de utilização do TopMostValue diferente de -1 ou 0 ?
Then, to finish this dialogue, could you give a functional example of use with different value of -1 or 0? Rogério Mauri