Como simular um clique em um jButton

Separe a lógica do actionPerformed() do botao “Novo” em um outro metodo, e chame esse metodo no lugar

Isso não é nada recomendável. Seu botão “Novo” deveria ser associado a um Action ou o seu ActionPerformed chamar um outro método. Você deve estar querendo clicar artificialmente no botão porque colocou o código dentro do actionPerformed(), acho que você deveria colocar fora e chamar a partir daí.

Olá,

Confesso que as dicas me deixaram um pouco envergonhado pela simplicidade que eu não havia enxergado.

Vou criar um método para o action Performed do botão novo e chamá-lo dentro do gravar. Voui estudar também como funciona o Action.

Obrigado.

Tipo, melhor ainda é vc ter uma classe que é responsável por fazer essas coisas, tipicamente a classe que tem acesso ao documento (JTextArea?).

bota uns métodos doNovo, doGravar, doXXX lá.

Seus botões, menus, não importa, chamam esses métodos.

Vc pode usar a mesma Action (a mesma instância) no menu, na toolbar, e nos botões. Não é a coisa mais intuitiva do mundo mas tem lógica, depois que vc aprendeu não esquece mais.

na sua Action, vc coloca:

actionPerformed(ActionEvent evt) {
    documentPane.doGravar();
    documentPane.doNovo();
 }

Bom, é uma sugestão. Na verdade é a sugestão do cv com exemplos.

O que vc perguntou não é o que vc queria saber. A resposta à sua pergunta é:

botao.doClick();

[]s!

Caro dukejeffrie,

Antes de mais nada obrigado. Sem querer abusar do seu conhecimento, e já abusando …

Tenho dúvidas em criar outra classe para ter os métodos dos botões do meu frame ( são jTextFied e jComboBox ). Não estaria criando classes demais para a funcionalidade de um frame ??? Isto não deixaria mais confuso a administração do meu projeto ??? Qual a real vantagem disto ??? Apenas separar em classes diferentes a visualização das ações ??? Você sugere que estas classes fiquem em pacotes diferentes ???

Tenho lido sobre MVC mas ainda não encontrei ( ou não entendi ? ) uma solução que me agradasse.

Abraços,

Márcio

Cara, sinceramente, nao recomento criar classes externas so para tratar eventos de botao, textfields, etc… Mas é mto melhor se vc criar métodos bonitinhos para tratar eles, deixando a classe interna.

JButton botao = new JButton("Add");
botao.addActionListener(new ActionListener(){
   public void actionPerformed(ActionEvent e){
      evtBotao_ActionPerformed(e);
   }
});

private void evtBotao_ActionPerformed(ActionEvent e){
   System.out.println("Clicado");
}

Acho assim mais bonito e melhor de trabalhar. Mas gosto é gosto e padrao é padrao…rsssss…
Abraços

Bom… não sou nenhuma autoridade no assunto, mas na minha opinião tem dois jeitos de vc encarar a coisa:

1. Vc trabalha com Actions. Entender a API é primordial pra não arrancar os cabelos depois. A idéia básica é que uma Action é um comando do usuário, não importa a origem (botão, menu, mouse gesture, comando de voz, programas de acessibilidade).

A coisa complica um pouco, mas centraliza a implementação se vc trabalha com várias origens pro mesmo comando. Suas Actions viram variáveis de instância e vc faz com elas o que quiser.

2. Vc trabalha com classes internas anônimas (código do brlima). Depois que vc acostuma, vira a coisa mais natural do mundo, seus olhos até passam por cima dos detalhes e vc lê só a chamada. Mas eu gosto de chamar meus métodos de doXXX, em vez de evtBotao_actionPerformed().

aliás, eu costumo escrever métodos com o que eles precisam, isto é: se eu preciso de um ponto na tela pra abrir um popup, eu declaro (por exemplo) doShowPreferencesDialog(Point p), e no actionPerformed eu faço as verificações necessárias.

De qualquer forma, o número de classes não muda nada. Em raros casos, quando vc precisa economizar muita memória, pode ser interessante criar um único ActionListener e fazer o coitado testar a propriedade actionCommand do evento. Mas é raro.

Criar muitas classes em um software com GUI é a coisa mais normal do mundo. Desde que vc não tenha código redundante nem copiado de um lugar pro outro, vc deve se ater ao fato de que uma classe tem umas poucas responsabilidades e só.

[]s!