| Autor |
Mensagem |
|
|
Você deve colocar seu JTree como sendo viewPort de um JScrollPane.
Na prática, ao invés disso:
Você teria isso:
Referência: http://download.oracle.com/javase/tutorial/uiswing/components/scrollpane.html
|
 |
|
|
|
O que você quer afinal? Uma janela maximizada? Um programa em tela cheia? Para mim ainda não está claro...
|
 |
|
|
|
Acho que mudar a máscara durante a digitação confundirá os usuários. Afinal, por que você precisaria fazer isso?
|
 |
|
|
Use outra linguagem (ou procure alguma função em outra linguagem que possa ser acessada via JNA, se quiser usar Java).
Sugiro isso pois Java não tem acesso direto a recursos do SO.
Isso quer fizer que não há como saber onde está determinada janela aberta, nem seu tamanho (na verdade, não é possível nem saber se a janela está aberta ou não).
Sem esses dados, não é possível tirar a captura de tela da janela específica.
|
 |
|
|
Você está tentando ler o arquivo todo para a memória RAM do celular. Como os recursos são bem limitados, acontece a exceção.
Ao invés disso, você deveria usar um pequeno buffer para receber os dados e ir salvando em disco (no cartão de memória ou na memória de armazenamento do celular).
|
 |
|
|
No Linux é fácil. Experimente rodar o seguinte comando no terminal:
Aí está a lista de programas em execução pelo usuário logado atualmente e o horário de início de cada um deles.
Isso poderia estar em um script que opcionalmente trata esses dados e direciona toda a saída desse comando para um arquivo de log.
O script poderia ser executado a cada 2 ou 5 minutos com uma entrada no crontab.
Já no caso do Windows, não faço ideia se é possível fazer algo parecido.
|
 |
|
|
|
Você quer dizer, realçar sintaxe no JTextArea? Tenho quase certeza que não existe uma forma simples de fazer isso.
|
 |
|
|
Muitos (senão todos os) serviços de e-mail limitam a quantidade de e-mails enviados por hora/dia e/ou o número de conexões simultâneas.
Uma solução que alguns provedores oferem é o uso de grupos de e-mail no servidor.
Um exemplo prático: usando Google Apps, pode-se criar um grupo com 10 mil pessoas e enviar apenas 1 e-mail que chegará para todas elas.
Isso reduz em milhares de vezes o tempo gasto no envio de e-mails. Isso pode ser crucial, principalmente em casos como o seu, em que o número de e-mails é absurdamente grande.
Entretanto, nem todos os provedores de e-mail têm uma funcionalidade semelhante. De qualquer forma, fica a dica.
|
 |
|
|
d34d_d3v1l wrote:resolveram 90% do meu problema... E agora, como transformar isso em tbelas?
Acho que antes respondermos isso, seria interessante termos uma visão geral de como seu sistema está. Você poderia fazer um diagrama UML de classes e postar aqui? Isso vai permitir sugerir melhorias tanto no código quanto na parte do banco de dados posteriormente.
|
 |
|
|
gilvan.sfilho wrote:
Cada venda terá um código, uma data, uma mesa e um cliente.
marcobiscaro2112, acho que data, mesa pode ser puxado direto do relacionamento, no caso a ocupacao. Então não tem por que armazenar a data e a mesa tanto na ocupação como na venda.
De fato, se a data estiver em alguma outra tabela, não há porque duplicar este dado.
Quando disse que cada venda tem uma data, mesa e cliente, não considerei que a utilização de uma tabela de ocupação. No caso, pensei em relacionar diretamente o cliente, com a mesa na qual ele sentou e quando ocorreu isso (ou seja, os dados da ocupação ficariam nessa mesma tabela).
Na hora de gerar o relatório, poderia ser feita uma consulta na tabela de vendas, filtrando pelo número da mesa específica. Com isso é possível saber quantos clientes passaram por aquela mesa em determinado dia, o valor total acumulado por mesa, etc.
|
 |
|
|
Sugestão:
Crie uma tabela de Vendas. Cada venda terá um código, uma data, uma mesa e um cliente.
Depois crie uma tabela de ItensConsumidos. Cada registro da tabela associará uma venda a um produto. Dessa forma, cada linha terá o código da venda, o código do produto e a quantidade comprada.
Note que a tabela de ItensConsumidos serviria de intermédio para a relação muitos-para-muitos entre Vendas e Produtos.
|
 |
|
|
c) Um construtor que receba a string (endereço WWW) completa
Acho que seu construtor está errado... Acredito que tenha que ser um construtor que receba só um parâmetro. Algo como:
|
 |
|
|
|
Usando setFocus e addActionListener
|
 |
|
|
O que exatamente você quer fazer?
No seu código, você está serializando os objetos. Por isso é de se esperar que caracteres estranhos apareçam.
Você quer salvar tudo em forma de texto? Como seria o formato do arquivo? Algo como CSV?
|
 |
|
|
Antes de mais nada: está muito bom visualmente e bem completo. Simples de usar, mas está incompleto, certo? A parte de relatórios ainda parece em desenvolvimento e os dados não são salvos em lugar algum.
Como você quer sugestões, vamos a elas:
* A frase "Registre antes de usar o programa" deveria aparecer na janela, como um rótulo, e não no título. O título poderia ser algo mais objetivo como "Registro"
* Os dados de registro, assim como todos os dados da aplicação, devem ser salvos de maneira permanente em algum lugar (banco de dados embarcado, talvez)
* Usar uma máscara para o telefone na tela de registro pode facilitar a vida do usuário e ajudar na consistência de dados
* Quando você indicar que todos os campos são obrigatórios, poderia dar o foco para o primeiro campo não preenchido
* Por que a contagem de mesas, código de produtos, de clientes, etc. começa do zero?
* A busca não funciona muito bem. Se eu procuro por 'enroladinho', não encontro nada, mas se eu pesquisar por 'salgado' o programa mostra os salgados da forma certa. Não seria interessante poder pesquisar em todo o nome do produto? Por exemplo, digito 'coca' e a busca funciona
* Na hora de dar entrada ou saída no estoque, o campo de busca só funciona se o nome bater exatamente (inclusive maiúsculas/minúsculas)
* Se o nome não bate na parte de estoque, a mensagem de elemento não encontrado é mostrada com problema de encoding (aparece 'não' no lugar de 'não')
* Qual gerenciador de leiaute você está usando? Na tela principal, alguns componentes do lado esquerdo da tela ultrapassam os limites das bordas (ao menos no Ubuntu, rodando sob OpenJDK)
* Quando edita-se o preço de um produto e coloca-se vírgula como separador decimal, o programa não faz nada (nem atualiza, nem avisa sobre erro). O mesmo ocorre digitando-se letras no campo de preço
* "Fechar" não deve ser um menu, e sim um item de menu
* Falta consistência de ícones (em especial os ícones grandes). Alguns são chapados, outros tem perspectiva, vários tem tamanhos diferenets, o que torna o visual inconsistente. Um exemplo bem óbvio é a diferença de visual entre os botões de adicionar e remover. Aliás, preste atenção na questão da licença desses ícones
* No lado esquerdo inferior da tela principal, os botões tem tamanhos diferentes
* Em alguns lugares (como na tela de relatório financeiro rápido) a tabela é editável (mas não deveria ser)
* Os relatórios rápidos são iguais
* O gerador de relatórios não funciona
|
 |
|
|