Exibir data em textArea

Boas pessoal…

sei que para pegar a data do sistema em tempo real devo instanciar um objeto date e usar o método currentTimeMillis() como no exemplo abaixo:

Date data = new Date(System.currentTimeMillis());

a minha pergunta é, como exibo isso, em formato Windows (dd/mm/aa) em um txt area?

se não, em qual componente devo exibir?

obrigado!

Pode ser assim:

Date data = new Date();
SimpleDateFormat df = new SimpleDateFormat("dd/MM/yyyy");
String dataString = df.format(data);

dai é so pegar a string e setar onde vc quiser.

Cara, isso mesmo que eu queria…

com essa solução cheguei à essa também, que também pega a data:


Calendar novoCalendario = Calendar.getInstance();
SimpleDateFormat dataHoraFormatada = new SimpleDateFormat("dd/MM/yyyy - hh : mm : ss");
txtAreaData.setText(dataHoraFormatada.format(novoCalendario.getTime()));

Agora só gostaria de saber como atualizo o horário, seja de segundo em segundo ou de minuto em minuto, só para atualizar mesmo, para não ser estático.

Obrigado!

Pelo jeito vc quer ficar exibindo na tela tipo um relogio.
Vc pode colocar este codigo em uma thread com sleep de 1seg.

Amigo, vc poderia exemplificar por favor?

Obrigado.

Um exemplo de relógio.


import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

import javax.swing.JLabel;
import javax.swing.Timer;


public class Relogio extends JLabel {

	public Relogio() {
		super();
		timerAtualizacao = new Timer (500, new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent arg0) {
				setText (df.format(new Date()));
			}
		});
		timerAtualizacao.start();
	}
	public void setFormato (String formato) {
		df = new SimpleDateFormat (formato);
	}
	private Timer timerAtualizacao;
	private DateFormat df = new SimpleDateFormat ("HH:mm:ss");
}

Exemplo:


import java.awt.BorderLayout;

import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.SwingConstants;

public class ExemploRelogio extends JFrame {

	private static final long serialVersionUID = 1L;
	private JPanel jContentPane = null;
	private Relogio lblRelogio = null;

	/**
	 * This is the default constructor
	 */
	public ExemploRelogio() {
		super();
		initialize();
	}

	/**
	 * This method initializes this
	 * 
	 * @return void
	 */
	private void initialize() {
		this.setSize(300, 200);
		this.setContentPane(getJContentPane());
		this.setTitle("JFrame");
	}

	/**
	 * This method initializes jContentPane
	 * 
	 * @return javax.swing.JPanel
	 */
	private JPanel getJContentPane() {
		if (jContentPane == null) {
			lblRelogio = new Relogio();
			lblRelogio.setHorizontalAlignment(SwingConstants.CENTER);
			lblRelogio.setVerticalAlignment(SwingConstants.CENTER);
			jContentPane = new JPanel();
			jContentPane.setLayout(new BorderLayout());
			jContentPane.add(lblRelogio, BorderLayout.CENTER);
		}
		return jContentPane;
	}

}


Note que:
a) É necessário usar um timer (para simplificar, usei um javax.swing.Timer). Não se deve usar Thread.sleep nesse caso.

b) Por que é que usei um timer de 0,5 segundo em vez de um de 1 segundo cravado?

  1. Se eu usasse um timer de 1 segundo cravado, às vezes você notaria que ele iria pular um segundo na hora de exibir - isso é porque um timer de 1000 milissegundos pode, por circunstâncias que o Java não pode controlar, ficar um pouco atrasado (mas nunca adiantado). Vá reclamar com o Bill Gates :slight_smile:
  2. Usando um timer de 0,5 segundos, além de eu não ter esse problema de ficar pulando segundos, eu teria um erro de no máximo 0,5 segundos na exibição do relógio, o que é normalmente suficiente para a maior parte dos casos.

c) Você pode reaproveitar essa classe Relogio em qualquer lugar onde você precise mostrar a data e hora corrente. No caso do NetBeans você pode até inserir uma instância dessa classe no seu formulário :slight_smile:

pra funcionar ta faltando o meto do main

public static void main(String[]args) {
  
      new  ExemploRelogio().setVisible(true);  }

tambem tirei o super das duas classes.
para que este super?

e o @override,

e funcionou bem.

É importante manter o super() pois ele chama o construtor das classes superiores. Ter funcionado bem sem eles pode ter sido um golpe de sorte.

O @Override não é necessário, mas é fortemente recomendado. Ele indica que aquele método está sobrescrevendo um método da classe pai. Assim, se você cometer um erro de sintaxe como escrever:

public void actionPeformed(ActionEvent arg0) {

O compilador não deixará o código compilar e te dará um erro dizendo que “actionPeformed” não sobrescreve método nenhum.

É útil também para quando você tem o controle da classe pai. Usar o @Override garante que, se você alterar o nome de um método que é sobrescrito no pai, todos os filhos receberão um erro até que alterem o nome do método também.

Note que sem o @Override no lugar do erro, você acabará com dois métodos declarados (o “actionPerformed” e o “actionPeformed”), e obviamente, um programa que não funciona.

interessante a explicação, um pouco eu ja fazia idéia. porém erros estão sendo previstos e

no caso o super da relogio, chama a propria jLabel que ele estende não ?

estou tendo usar esta classe relogio na minha aplicação até, investigar melhor seu fucionamento e talvez colocar direto, ou deixar assim mesmo.

porque é complicado colocar uma data no swing, não achei que fosse tão dificil. não aceita na label e nem no textfield.

??? e quando vai como string, nao se atualiza automatico.

O meu programa também serve para mostrar a data.

Basta você mudar “HH:mm:ss” para a formatação adequada, por favor veja em:

http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/text/SimpleDateFormat.html

Por exemplo, para pôr a data “21/07/2010”, use “dd/MM/yyyy”.

[quote=ViniGodoy]É importante manter o super() pois ele chama o construtor das classes superiores. Ter funcionado bem sem eles pode ter sido um golpe de sorte.

O @Override não é necessário, mas é fortemente recomendado. Ele indica que aquele método está sobrescrevendo um método da classe pai. Assim, se você cometer um erro de sintaxe como escrever:

public void actionPeformed(ActionEvent arg0) {

O compilador não deixará o código compilar e te dará um erro dizendo que “actionPeformed” não sobrescreve método nenhum.

É útil também para quando você tem o controle da classe pai. Usar o @Override garante que, se você alterar o nome de um método que é sobrescrito no pai, todos os filhos receberão um erro até que alterem o nome do método também.

Note que sem o @Override no lugar do erro, você acabará com dois métodos declarados (o “actionPerformed” e o “actionPeformed”), e obviamente, um programa que não funciona.[/quote]

O super() também não é necessário, a classe filha sempre chama o construtor da classe pai. Se você não especificar o construtor na filha, ele vai chamar o construtor default, e caso não existe um construtor default na classe pai, ai sim você vai ser obrigado a chamar um explicitamente, senão vai dar erro de compilação.

[quote=dm_thiago]
O super() também não é necessário, a classe filha sempre chama o construtor da classe pai. Se você não especificar o construtor na filha, ele vai chamar o construtor default, e caso não existe um construtor default na classe pai, ai sim você vai ser obrigado a chamar um explicitamente, senão vai dar erro de compilação.[/quote]

Como as regras são um pouco complicadas (você levou mais de duas linhas para explicá-las :slight_smile: ), eu prefiro chamar eu mesmo (não, nunca fui programador Cobol e não gosto de escrever coisas a mais). Mas se é possível haver alguma confusão, opto por não haver confusão - é a mesma coisa que omitir as chaves quando o if, ou while, ou do/while; é possível mas costuma dar alguma confusão depois de alguma manutenção no código.

Tem razão, devo ter me confundido de linguagem.
Mas ainda sou da filosofia do entanglement. Tem certas coisas que são melhores deixar explicitas.

[quote=entanglement]
Como as regras são um pouco complicadas (você levou mais de duas linhas para explicá-las :slight_smile: ) [/quote]
hauhauhauahuahauhauhau

[quote=entanglement]
Mas se é possível haver alguma confusão, opto por não haver confusão - é a mesma coisa que omitir as chaves quando o if, ou while, ou do/while; é possível mas costuma dar alguma confusão depois de alguma manutenção no código. [/quote]

Concordo totalmente! Só quis deixar claro que não daria problemas suprimir aquele super() ali.