| Autor |
Mensagem |
|
|
Mmmmm perai. Pelo que eu entendo de thread se voce fizer:
Thread t = new Thread();
try {
t.sleep(5000);
.
.
.
O sue thread t é que dorme por 5 segundos não sua aplicação. O código deveria passar rapidamente por isso e imediatamente executar o set visible false. (Me corrijam se eu estiver errado).
Agora voce pode fazer
O que acontece é que você parece não conhecer bem sobre threads java. Você chamou o sleep() sem nem mesmo dar um Thread.start(). O que, ou não faz nada ou lança uma exceção.
Claro que essa solução que dei talvez não seja a melhor (criar uma nova classe para algo simples), mas ela mostra os conceitos de Threads, como start() sleep() etc... Leia o Core Java volume 2 capítulo 1 - Threads. Muito legal e você aprende muito sobre eles.
Qquer dúvida...
|
 |
|
|
|
O descompilador, algumas vezes, não consegue encontrar os nomes dos métodos, daí colocar esses nomes malucos como zzzh etc... Como originalmente esses métodos/classes não existem, ele não pode compilar a classe.
|
|
|
|
Por default, quando se executa os aplicativos a partir do próprio netbens, eles são executados na pasta da instalaçao do mesmo. No meu caso por exemplo é c:/netbeans3.4
Logo se vc tentar abrir uma imagem como "imagens/algo.gif" seu programa tentará abrir c:/netbeans3.4/imagens/algo.gif.
Só que não sei como configura isso não. Nunca passei por este problema.
Mas tenha isso em mente. O netbenas chama o java normalmente a aprtir desta pasta.
|
|
|
|
|
Parece que muita gente tem tido problemas com o ME. Não é à toa. O ME foi o pior SO da Microsoft. Se você puder, tente o Win2K professional. Muito legal mesmo.
|
|
|
|
|
Há, IvoD, boa sorte se precisar construir uma aplicação swing complexa no "hardcode".
|
|
|
|
Vamos deixar de ser ridículo. Vamos parar de fanatismo. Se o Delphi fosse ruim, se sua IDE fosse uma droga, se a sua filosofia não prestasse, não vendia tanto. Não tentem me convencer de que um editor de texto é melhor que um editor gráfico. Simplesmente não é. Nunca vai ser. Se você está trabalhando com JBuilder, termine seu projeto com o JBuilder. Agora, querer fazer tela com o JBuilder e terminar o programa com o Eclipse. E se precisar mexer no frame de novo, e no código de novo. Só porque o Eclipse coloca um botãozinho do lado do código errado??????
Eu particulamente não gosto muito do JBuilder, prefiro o Netbeans. Mas o uso no meu trabalho sem problemas, utilizo seus recursos, que são bons, mas não fico trocando do JBuilder para o Netbeans só pq o NB dá suporte ao setExtendedState.
Coloquem duas pessoas capacitadas trabalhando, que conheçam a ferramenta e vamos ver quem termina um editorzinho de texto primeiro.
Não sejam como aqueles freaks do linux. O sistema é bom, mas não é a única solução do mundo, que dá graças à deus por existir powerpoint. Já basta os fanáticos religiosos, deixem a computação de fora.
----Odeio Fanatismo----
|
|
|
|
Meu amigo, sinceramente, pra que esse malabarismo todo. Se você já vai usar o JBuilder para fazer a tela swing, por que não usar pro resto???? O Eclipse não é esse bam bam bam todo em relação ao JBuilder não. O JBuilder é muito bom tb.
Agora imagine que você faz o frame, vai para o Eclipse e programa. Precisa fazer mais alterações no Frame, volta para o JBuilder... pra que??? Faz no JBuilder mesmo.
Além do mais, se você alterar o código que o JBuilder gera, ele tem dificuldade para reconhecê-lo.
Vamos deixar de fanatismo. O eclipse é bom? Pode até ser (não conheço), mas se ele não atende a necessidade, use outra ferramenta. Você pode acabar perdendo produtividade.
|
|
|
|
|
Adoro testar meus conhecimentos. Me gratifica bastante poder ajudar os outros. Ainda sou iniciante em java, mas já tenho uma pequena bagagem. Ao expor minhas idéias dou oportunidade para que outros a comentem, sugiram melhorias ou simplesmentem digam que elas são uma droga (se bem que aí vão ter que me convencer).
|
|
|
|
Uma outra opção, que utilizamos aqui na empresa, propicia uma transparência de banco de dados sem recompilação de código, mas você ainda não pode fugir do SQL.
Nós usamos a arquitetura em camadas do CESAR, daqui de recife, veja como ela funciona:
1 - A arquitetura é dividida em várias camadas
Esta arquitetura permite que, se você precise fazer alguma alteração na aplicação, a penas a camada responsável é modificada, sem afetar as demais. Você pode até mesmo trocar uma camada por uma outra, implementada de forma diferente e tudo funciona blz.
Mas vamos a parte que interessa. Entre a camada de negócios e a camada de repositório, existe algumas interfaces com métodos de persistência apropriados para cada entidade persistente. Por exemplo, vamos supor que temos duas classes que precisam ser persistidas: Cliente e Pedido. Criariamos duas interfaces IRepositorioCliente e IRepositorioPedido com os métodos:
Agora para cada banco de dados em específico, criamos uma classe que implementa IRepositorioPedido ou IRepositórioCliente, por exemplo
ClienteOracle, ClientePSQL, ClienteMySQL, que ao implementar os métodos da interface, utilizam os SQL correspondente de cada banco.
Para a camada de negócios, existe então apenas a interface. Você cria instâncias do repositório através de uma Factory e se precisar mudar o banco, precisamos apenas mudar um property em algum arquivo de texto para que a Factory comece a criar repositórios do novo tipo de banco.
Desvantagens:
Você precisa ter uma classe para cada entidade persistente para cada banco.
Vantagens:
Seu repositório pode ser qualquer coisa, uma banco Oracle ou Interbase, um arquivo XML, um txt, um stream pela rede para algum servidor em outro lugar, entre outros.
Não há necessidade de recompilação (a não ser que o novo repositório não exista e ainda precise ser criado, mesmo assim, só precisa compilar o código do NOVO repositório)
|
|
|
|
|
Certo, mas você ainda não consegue acessar as variáveis de ambiente. Alguém sabe como fazê-lo.
|
|
|
|
Pelo o que eu pude ver através do código código, detectei alguns erros de lógica.
Veja bem, quando vc faz
O F que você esta fechando é o F da instancia implicita this.
Ou seja ArmazemLocaliza a = new ArmazemLocaliza(); está aí de bobeira.
Se você que dar o dispose() no objeto criado "a" deveria chamar a.F.requestFocus() e a.F.dispose();
Por que você não nos diz exatamente o que quer fazer?
|
|
|
|
Cuidade. "user.dir" retorna a pasta em que a classe esta executando e não onde ela está localizada.
Por exemplo, ao executar um arquivo teste.class que se encontra em c: emp a partir do Netbeans, "user.dir" retorna "c:
etbeans3.4" (minha instalação do Netbeans)
Se, contudo, eu acessar a pasta e executar a classe, ela retorna "c: emp".
A dica acima só funciona se for dada a garantia que o ambiente de execução esteja localizado na pasta de sua aplicação.
|
|
|
|
|
Não acho que sej abug não. Segundo a documentação de pack() ele é responsável por iniciar uma série de eventos para a exibição do Frame. Deve ter alguma relação. Só não sei qual.
|
|
|
|
Mermãããão. Basta colocar o o diretório bin no path.
Como fazer isso?
Edite o autoexec.bat
Procure pela linha PATH=...
Adicione o caminho completo até o bin do java
Por exemplo:
É necessário reiniciar a máquina para que as alterações tenham efeito.
(O autoexec.bat fica na pasta raiz do seu HD)
|
|
|
|
Opa! No código anterior, o setExtendedState() foi posto por mim à mão. Se eu pedir para o NetBeans gerar o código para mim não funciona, pois o setExtendedState aparece dentro do initComponents() e antes do pack().
Mesmo que eu tire a chamada à pack() o código não funciona. Mas se logo após initComponents() eu invocar setExtendedState(), aparecendo então duas vezes no código, uma dentro de initComponents() e uma após, funciona normalmente.
??????????????????????????????????????????? 
Tentem chamar pack() e logo em seguida setExtendedState(). Apenas nessa situação consegui colocar para funcionar.
Iruuuuuu. è isso mesmo. Testando o código que o netbeans gera, uma chamada setExtendedState() antes do pack() (ou sem a presença do pack()) não funciona. se você chamar setExtendedState() após pack() rola blz.
O mesmo vale para o JBuilder.
|
|
|
|