| Autor |
Mensagem |
|
|
Não tem como o leitor parar com as leituras (pelo menos usando somente java. Talvez com Java + JNI + C).
De qualquer forma, o sistema não vai mais capturar as leituras indesejadas e vai se comportar direitinho se você tirar o foco do campo.
É o "beep" do leitor que tá incomodando? 
|
 |
|
|
|
Bom, ai voltamos para a minha primeira resposta. Se você não quer que ele leia, simplesmente tirar o foco do campo de texto não ajuda?
|
|
|
|
Imagino que, se o leitor é configurado para ficar lendo intermitentemente, mesmo não enviando informações para o sistema, não há o que fazer.
Ficaria parecido com os leitores usados nos caixas de livrarias. Eles estão sempre funcionando, mesmo que não estejam lendo códigos. Ai a balconista passa o código e ele lê. 
O máximo que eu já vi sobre leitores de código de barras é que eles são programáveis sim, mas o que eu usei, no caso, programava-se lendo códigos do manual de instruções dele....mas acho que isso não te ajuda. 
|
|
|
|
hmmm.....não entendi. O fato do leitor ler intermitentemente os códigos está atrapalhando?
Se for isso, faça com que a aplicação não leia o que vier do leitor.
Imagino que, para que o leitor entre com a leitura do código na aplicação, a mesma deve estar com foco num campo de texto. Tirar o foco do campo não resolve? 
|
|
|
|
Hmm....e onde você acha que as regras de negócio devem estar?
Você criou os objetos....mas pensando nas tabelas. Nota-se isso por vários dos métodos que você criou. Se tivesse pensado nos comportamentos primeiro (ou, se preferir, regras de negócio) saberia que elas deveriam estar nesses objetos.
(procurando links para os posts do site fragmental do pcalcado, em português e não encontrando nada além de páginas da web perdidas ao vento...)
Bom, procure na internet sobre modelos de domínio no google. Vai ajudar.
|
|
|
|
|
Começar do banco de dados é começar procedural. Se você vai fazer em java, porque não começar com os objetos?
|
|
|
|
Já estou inscrito!
|
|
|
|
bglbruno wrote:Rodrigo, funcionou da forma que disse! Configurei para as dependencias irem para a pasta lib.
Mas, agora tenho outra exception
Os dois jars estão presentes, e com todos .class
slf4j-log4j12-1.6.1.jar
slf4j-api-1.6.1.jar
O que pode ser agora?
Obrigado pela ajuda galera!
É a versão do slf4j que o commons-logging está usando.
A versão do commons que você colocou no projeto utiliza uma versão do slf4j diferente da que você colocou no seu projeto. O commons tentou usar um método de uma classe do slf4j que não existe na tal classe. Daí a exceção.
Verifique no site do projeto qual versão você deve usar.
|
|
|
|
BrunoFurtado wrote:
E o esquema q vc falou ai meio que faz com que o Maven não exerça sua principal função.
Essa tarefa é realizada pelo plugin do eclipse. Não tem nada a ver com o maven.
BrunoFurtado wrote:
O Maven geralmente não compila os arquivos .JAVA quando estão fora da estrutura "src/main/java".
As classes que ele não compila são as do projeto, não das suas dependências. No caso, ele está tentando importar uma biblioteca, que já foi compilada um dia.
BrunoFurtado wrote:
Provavelmente, neste caso, o JAR da Caelum não tem essa estrutura padrão Maven e ai ao compilar o Maven não encontra e não gera o .CLASS.
Não não Bruno. Pouco importa se a biblioteca segue ou não a estrutura padrão do maven. É só criar a biblioteca e colocar no repositório do maven. A não ser nos casos em que essa biblioteca tenha dependências. Mas no caso do VRaptor, ele é a biblioteca que possui dependências. Então o bglbruno não deveria ter tomado ClassCastException. Acho que o erro é simplesmente esse que você citou mesmo (a biblioteca não foi "deployada" pelo eclipse).
BrunoFurtado wrote:
As vezes o Maven atrapalha...
Ah, sei lá, eu gosto!  Mas tem algums problemas sim.
|
|
|
|
Complementando o post do BrunoFurtado:
Se o JAR não estiver presente, provavlmente é um dos (muitos) bugs do plugin do maven para o eclipse. Gere o war usando linha de comando mesmo. E pra não ter q fazer isso toda vez que compilar, com o botão direito, clique no seu projeto e acesse Properties -> Deployment Assembly. Vá na aba de mesmo nome e verifique se as dependências importadas com o maven (ou mesmo uma variável 'maven dependencies') estão configuradas. Se não tiver, dá um 'add' e as adicione.
|
|
|
|
|
Dá pra empinar pipa na laje de uma casa sueca?
|
|
|
|
|
Você está conseguindo importar a classe VRaptor dentro das suas classes?
|
|
|
|
Posso estar errado, mas JavaFX faz a mesma coisa que o Swing faz, mas em outra linguagem.
Outro dia estava pesquisando ferramentas para desenvolvimento em flash para interfaces desktop e encontrei essa aqui. Veja se pode lhe ser útil:
http://djproject.sourceforge.net/main/index.html
|
|
|
|
Que tal começar com a construção de algumas classes como Endereço, Paciente, ..... er....... Ficha,....
Sim, o sistema é pequeno, eu sei. Mas fazer bem desde o começo pode ser uma boa!  Inclusive na escolha das tecnologias a serem usadas.
|
|
|
|
Gustavo Marques wrote:Sim, também vejo a padronização como um grande benefício. É lógico que dá para trabalhar da maneira atual, mas cada um faz do seu jeito, ou usa double, big, classe wrapper, vira uma salada.
Além de virar uma salada, tem também o problema da precisão do resultado. Cálculos devem ser, digamos, precisos. Ainda mais quando se trata de cálculos monetários, lidando com dinheiro dos outros. E todos nós sabemos que trabalhar unicamente com tipos primitivos para realizar operações matemáticas pode gerar muitos resultados errôneos.
O Java já possui classes para muitos tipos básicos, como Integer e String. Uma classe Money (de forma semelhante ao pattern citado no livro do Fowler) cairia muito bem pra plataforma.
(OBS:apenas citei o pattern por não conhecer implementação melhor para representar dinheiro)
|
|
|
|