Salve turma,
estou com um problema e se alguém pudesse me ajudar, ficaria muito agradecido.
Estou trabalhando com swing e gostaria de saber se alguem conhece uma forma de controlar a ordem do TAB nos objetos da tela.
Agradeço.
Junior.
Olá
Veja:
http://java.sun.com/developer/JDCTechTips/2002/tt1022.html#2
http://java.sun.com/j2se/1.4/docs/api/java/awt/doc-files/FocusSpec.html
http://java.sun.com/docs/books/tutorial/uiswing/misc/focus.html
http://java.sun.com/docs/books/tutorial/uiswing/events/keylistener.html
[]s
Luca
Oi Luca,
acho q vc saca de Interface Swing, por isso resolvi especificar meu problema.
Existe um campo na tela que não consegue receber o foco. Tenho um JList, dois JButton e outro JList, e neste último o foco não passa por ele.
Já vi o isFocusable dele, está true.
E não sei o motivo disto.
Direcionei a Luca, mas quem quiser particiar da resolução eu agradeço.
Abraços.
Olá
Luca é apelido de Luiz…
Difícil saber o que ocorre no seu código. As vezes já fico doido com o meu. Aconselho a vc uma boa estudadada nos links que passei e em mais este aqui: http://www.developer.com/java/other/print.php/2198221
Abaixo um pequeno resumo dos conceitos básicos de foco em Java tirado dos links passados para vc.
Antes do J2SDK 1.4 o sistema de foco era inadequado e cheio de bugs. Uma das piores coisas era a impossibilidade de saber qual o componente que estava com o foco. Quando um componente recebia um evento FOCUS_LOST não havia meios de saber qual componente recebia o foco.
Para resolver deficiências tais como as citadas acima foi desenvolvido um novo modelo de foco para o AWT no J2SDK 1.4. As principais mudanças vieram da construção de uma nova classe centralizadora KeyboardFocusManager e uma arquitetura de foco leve não baseada em componentes nativos.
Visão geral de KeyboardFocusManager
Sete principais conceitos:
[list]
-
focus owner - componente que recebe o foco
-
permanent focus owner - último componente com foco. É o mesmo focus owner a menos que esteja em meio a uma mudança temporária de foco.
-
focused Window - Window que contém o focus owner
-
active Window - Frame ou Dialog que é a focused Window ou o primeiro Frame ou Dialog que é o dono da focused Window
-
focus traversal - possibilidade do usuário trocar o foco sem mover o cursor (sem mouse, usando TAB)
-
focus traversal cycle - porção da hierarquia do componente que atravessatodos os componentes do ciclo de foco
-
focus cycle root - Container que é a raiz da hierarquia do componente para um determinado focus traversal cycle
[/list]
Toda Window e todo JInternalFrame é por default um focus cycle root.
Fico por aqui…
[]s
Luca
Oh cara,
Valeu mesmo, fico lhe devendo uma.
Junior.
Aproveitando o encejo: Luca, pra validação de campo, se vc precisa exibir uma mensagem nao permitindo que ele saia do campo enquanto nao digitar algo certo, mas que dependendo do botao, permitisse.Ex:
o cara precisa digitar o codigo do estado correto para gravar. Nao pode salvar, incluir e nem rolar para o proximo registro, mas pode excluir e limpar os campos.
Eu confesso que o negocio é critico, pelo menos pra mim travava minha aplicaçao direto quando exibia a caixinha de dialogo e voltava pro campo. Tudo por causa do foco.
Depois de um certo tempo fiz uns metodos loucos que ate hj naum entendi, mas funciona. So nao tenho mta confiança.
Fiquei curioso pra saber se vc ( ou mais alguem ) passou por isso e como resolveu este problema.
Abraços.
Um bom jeito pra sair dessa emboscada, Bruno, eh evitar ao maaaaaaaaaximo usar janelas de dialogo. O que eu faco aqui geralmente eh exibir uma mensagem de erro (um JLabel) logo ao lado do campo, e pintar a borda do componente de vermelho (pra ficar bem evidente o que esta errado). De quebra, eh soh desabilitar os botoes que nao podem ser clicados ate que a acao deles possa, de fato, ser executada 
Salve turma…
Bruno,
eu não sei como é que entá montada a sua aplicação, mas vc não podeira fazer essa validação e uma outra “camada”?
O que nós fazemos aqui é isso, toda a tela é validada campo a campo em uma em uma camada tipo Model(negocial) e caso haja algum problema ele retorna onde foi o erro.
Não sei se essa é a maneira mais correta, mas nós estamos usando aqui e tá legal.
Se vc precisar que eu seja mais específico, estou aqui pra ajudar.
Francisco.
Meus caros,
Usuário é um mer%#$. Eu logo de cara no incio do projeto pensei: "Ah , vou validar na hora da inclusao, dai antes de incluir eu chamo uma camada de validacao e pronto!"
Dai vem alguem e me fala: “Mas eu quero que me avise se eu digitar errado.” E eu falo: “Blz vou coloca um label no rodape”.
Ai começar: "Mas eu quero uma mensagem pra me avisar e eu parar de digitar… "
:?: :?: :?:
Agora vai explica que é uma bosta de usar a dialog…
A sua ideia, cv, é bem legal do label e pintar o componente… Mas vc conhece usuario cri cri… Quer janelinha e nao quer saber de mais nada…
Um dos problemas q enfrento é : onde fazer a consistencia do campo ? FocusLost esquece que se vc clicar no botao, ele executa o botao e depois dispara o focusLost do campo. Mesmo pq se for um outro botao, nao precisa validar… Argh… complicado… odeio essa vida… rs… :shock:
O usuario precisa tirar as maos do teclado pra poder clicar num dialogo (nao me venha dizer que os caras sabem apertar enter, s/n ou o/c num dialogo, pq eu NUNCA vi ninguem fazer isso. Outro problema de usar mtos dialogos eh que o usuario quase sempre ta olhando pro teclado ou pra um papel quando esta digitando, e nao necessariamente pra tela. As vezes o cara apertou Yes e nem sabe, pq estava no meio da digitacao.
Mas, se esses argumentos nao convencerem, faca uma sessao de paper prototyping com um cronometro na mao, e veja como demora mais pra preencher um formulario cheio de dialogs 
boolean isValidated = false;
...
if(!isValidated) {
// validar o formulario
}
// executar o resto do codigo
Precisa de mais alguma coisa?
Pessoal,
Concordo com o Bruno, às vezes a melhor crítica é impedir a digitação em si e não validar um monte de campos todos errados. Em algumas janelas é melhor validar campo a campo. É o modo “janela” de validar um formulário ao contrário do modo “form” que é usado na internet. Numa janela tem-se muito mais controle sobre os eventos e este controle deve ser aproveitado. Outro dia pus um post sobre JTextFieldNumérico justamente com isso em mente. Se um campo é inteiro a caixa de texto não deve deixar o usuário digitar nehum valor inválido pra começar, e não deixar o infeliz digitar um monte de besteira e depois tratar em um botão ou evento. Até porque mais tarde ainda será necessário determinar quem está com conteúdo irregular e dar foco neste controle, pelo menos isso seria o certo.
Aproveitando o tema não descobri como saber qual é o controle com foco num determinado momento. tentei o código abaixo mas não funcionou.
Component compFocusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner();Eu queria testar o valor de um JTextField antes de sair dele. Se tiver algo errado quero interromper a saída, mas se o controle que ganhar foco for um botão tipo “Cancelar” a saída é permitida. Acho que foi sobre isso que o Bruno estava falando.
Abraços…
Uma tática comum e que, quando bem executada, faz sucesso, resume-se um pouco a deixar os campos fáceis de inserir (como texto livre, etc) como texto direto no formulário, e deixar outros campos apenas mostrados, e fazer diálogos pra eles (com aquele botão “…”);
Por exemplo, é muito mais fácil entrar uma data se vc tiver:
- Um campo com o formato especificado (p.ex. “[…/…/…]”)
- Um calendário que percebe mudanças no campo e indica a data digitada, mas que pode ser usado também para o input
Isso pq um campo de texto (ainda mais formatado) agiliza a entrada de dados, enquanto um calendário agiliza a conferência.
Alternativamente, os velhos combos de Dia e Mes + um Field pro ano. Lembre-se de mostrar a data completa num text field.
Assim vc pode fazer um formulário completamente dedicado à validação do campo. Só que ocupa espaço, e muitas vezes vc quer um formulário que corresponda ao papel preenchido à mão que o usuário vai passar pro micro.
90% das vezes que eu vi isso foram em aplicações que requerem uma entrada de dados muito ágil, como aquelas apps em Clipper (pra virar clichê) pra locadoras, academias, etc.
Além disso, é interessante tornar o mouse supérfluo. Pessoas treinadas conseguem guardar de cabeça sequências como F1, 3, F4, <texto>, 3xEnter, F5, Enter.
[]s!