| Autor |
Mensagem |
|
|
Testei a aplicação tanto no JBuilder quanto no NetBeans. No Netbeans rodou tudo ok, mas no JBuilder7 não (sinceramente, não gosto do JBuilder). Já passei por esse problema. A tarde, se ninguém mais responder, digo como fazer. Como já disse, tem um amigo meu que conseguiu botar pra rodar no JBuilder.
Vou colocar o código que o netbean gera (Ah! Não tem problema em usar o pack() não)
|
 |
|
|
|
Lembrem-se de que esta funcionalidade só está disponível a partir do J2SE 1.4. Na API javadoc, ele alerta que alguns sistemas operacionais não suportam certos estados. No Windows2000, comigo, funcionou tranquilamente. Se estiverem usando JBuilder, lembrem que até a versão 7 ele ainda usa o J2SE 1.3. Verifiquem se após o código de vocês é executado o método pack(). Acredito que ele "desformata" o maximized. Alguém no meu trabalho teve o mesmo problema usando JBuilder (eu uso NetBeans) mas conseguimos resolver. Mais tarde retorno e vejo o que pode ter ocorrido.
|
|
|
|
Os threads em java sempre terminam ao chegar ao final do método run().
É necessário um loop para que ele aceite várias requisições.
Lembre-se de ter um finalizador para quando quiser terminar o laço.
|
|
|
|
O código acima não maximizará a tela, mas sim setará o tamanho para o tamanho da área de trabalho, o que é diferente. Quando a tela está maximizada, você não pode move-la e o botão de maximizar está desabilitado.
O recurso de maximização só está disponível a partir do J2SE 1.4 (se não me engano, sei que o 1.31 não tem).
basta usar
|
|
|
|
Carlos H está certo. O compilador acusará erro (algo do tipo "ambiguos declaration").
Recentemente implementei um pool de recursos (baseado no livro JSP Avançado) e foi a partir desta experiência que pude finalmente visualizar quando um classe abstrata é necessária.
Como o pool era um pool de recursos genérico (pode conter conexões com BD, I/O ou beans), uma implementação via interface se mostraria bastante inificiente. Porquê?
Uma interface é um contrato uqe a classe promete cumprir, como já explicado anteriormente. Tudo bem, ela deve implementar os métodos necessários ao usuário do pool (getResource()). Agora como ficaria o código que gerencia os recursos do pool?
Se usássemos apenas interfaces, teríamos que reimplementá-los, com uma classe abstrata resolvemos o problema.
Vamos dar uma pequena analisada no código.
Agora, se quisermos um pool de conexões, bastamos estender a classe AbstractResourcePool e implementar os métodos createResource(), isResourceValid(Object resource) e closeResource(Object resource). Para este caso específico, em createResource(), criamos uma nova conexão
em closeResource() fecharíamos a conexão
e em isResourceValid()
Espero ter sido útil.
|
|
|
|
E mais uma coisa. Se não for especificado nenhum modificador de acesso, então o método/atributo, o que seja, é visível apenas dentro do mesmo pacote, tendo uma visibilidade default. A hierarquia ficaria +- assim.
|
|
|
|
|
É isso mesmo. A partir da versão 2.0, métodos como updateXXX() e updateRow() foram adicionados. Procure na API javadoc que deve haver algo falando sobre isso. Ou leia no livro JDBC e Java da O REILLY
|
|
|
|
|
A partir de JDBC 2.1, se não me engano, o ResultSet já reflete as operações sofridas automaticamente no banco. Não sei bem se é o próprio ResultSet ou alguma classe filha dele. No Core Java ou no livro de JDBC da O'Relly tem algo sobre isso. Quando eu confirmar, se ninguém já o tiver feiro, eu volto e respondo.
|
|
|
|
Por que você mesmo não fecha a janela do JTable manualmente. Basta ter acesso a referência da janela. Até mesmo em Delphi o processo tem que ser manual. Para soluciona-lo, faça a janela modal e crie um código como o seguinte.
Como a janela é modal o foco não pode retornar ao programa a menos que você a feche, e, ao fechar, o método dispose é chamado para liberar os recursos alocados.
Caso a janela não seja modal (i.e. o usuário pode continuar interagindo com o programa) é necessário guardar a referência da janela, para que possa ser chamada o dispose automaticamente.
|
|
|
|
|
Core Java é O LIVRO sobre java. Mais importante do que mostrar a tecnologia, ele nos mostra como ela funciona. Muito didático e interessante. o livro de Deitel é chato e, acima de tudo, foca muito swing.
|
|
|
|