| Autor |
Mensagem |
|
|
Sempre tem. Precisa ver quanto vc quer gastar de energia nisso.
O mais lógico é usar a única coluna do JComboBox pra mostrar tudo o que vc quer mostrar. Se vc quer mostrar o código e o nome do cliente no JComboBox, vc pode implementar uma classe assim:
Pronto, vc pode adicionar esses elementos diretamente ao JComboBox, que ele vai mostrá-los bonitinho. Quando vc precisar do código, vc pode fazer assim:
Sei lá... isso aí serve?
aquelão!!
|
 |
|
|
Calma, galera!!
O Código em azul não precisa ser editado na mão. Tudo o que está ali pode ser editado através do inspector (propriedades, eventos, tamanhos, layouts, etc).
Mesmo coisas meio esquisitas de editar, como nomes de método, podem ser configurados.
Fuçem bastante pra descobrir, pq vale a pena: quando vc pega prática, dá pra fazer interfaces MUITO rápido.
tudo de bom!!
|
|
|
|
Fala, pessoal.
Esse assunto é bem chato no começo, até pegar a idéia principal. Você pode enxergar uma classe como tendo um "nome completo" assim:
Outras classes do mesmo pacote conhecem a classe pelo "primeiro nome" (no caso, ArrayList).
Quando vc vai executar sua classe, vc tem que passar na linha de comando o nome completo dela. No seu exemplo, sua classe chama-se "teste", então ficaria assim:
Não parece importante no começo, mas é sempre bom dar nomes com letra maiúscula para suas classes. Além de vc correr o risco de receber mensagens estranhas do compilador, pode ficar muito difícil para outra pessoa ler seu código.
Existem muitos padrões para nomes de métodos, de membros, de classes, de pacotes, até de onde coloca as chaves. É uma boa ir descobrindo os vários e usando os padrões que vc gosta mais.
Boa sorte!!
|
|
|
|
Fala, rb!
eu só posso falar do JasperReports, pq o JFreeChart eu nunca usei. Acho que vc não vai conseguir colocar um gráfico dentro do report. Mas vc pode, talvez, montar um jpeg, se vc souber desenhar o report (tem métodos pra isso na API).
Se vc precisa de um PDF, vc pode mexer direto com o iText, que é a biblioteca de PDF que fica por baixo do Jasper. Dá o triplo do trabalho, mas fica profissa.
Talvez se vc der um exemplo de resultado final, dê pra dar mais alguma idéia.
aquelão!!
|
|
|
|
Meu, pra que fazer de novo uma coisa que já existe? Por que a gente não faz alguma coisa que NÃO existe??
Sou contra gastar energia onde não precisa.
Aquelão!!
|
|
|
|
Meu caro galvim, vc não está apanhando do Java. O problema é que vc tem na sua mão uma API gigantesca com alguns anos de reformulações.
Quem sabe eu escrevo algum artigo/tutorial/etc aqui sobre a relação entre AWT, Swing e JavaBeans. É bem interessante e vou ter uma desculpa pra aprender isso direito. 
Mas essa regra que eu venho usando há algum tempo serve sempre: "se parece muito difícil de fazer, tente outra abordagem". No Swing não tem nada faltando, vc só precisa fazer algumas customizações. Entender o MVC também faz diferença: 80% das vezes vc vai usar os widgets de sempre pra mostrar seus dados de um jeito estranho, isto é, vai mexer no model. Outros 15% (essa estatística é inventada, tá??), vc vai mudar cores e layout, ou seja, o View. Precisar mexer no Controller é raríssimo.
abraço!
|
|
|
|
Cara, que furada!!
Não tem nenhum jeito simples de pegar o JScrollbar do combo box!! Nem olhei de tanta certeza que eu tinha...
Eu tive uma idéia que pode não resolver, mas vai te dar um caminho pra pesquisar. Existe a classe DefaultComboBoxModel que vc pode usar pra mudar como o ComboBox acessa sua lista.
Ou seja, vc provavelmente tem uma classe que consegue dizer em qual "janela" do seu ResultSet vc está dada uma posição nessa janela. Vamos supor que a sua lista tem 10 mil itens, e cada janela contém 100 itens, então o item 456 está na janela "401-500", certo?
Vc pode fazer uma subclasse do DefaultComboModel em que vc reimplementa o size() para devolver 10 mil, e o getElementAt() pra descobrir se vc tá na janela certa, mudar de janela se precisar, e pegar o item certo.
Desse jeito, vc só mexe no código que interessa: o do model. Eu briguei bastante com vc na outra thread pq eu cismava que vc estava gastando energia à toa. A Patrícia tb desistiu de postar. Mas eu sou mais teimoso que todos vcs juntos e vou sempre dizer que não precisa pegar esse evento do mouse no scroll bar pra fazer isso, pq vc tá num modelo MVC. 
Mas, do fundo do coração, torço pra vc conseguir fazer seu loading gradual. Boa sorte!!!
|
|
|
|
Se eu entendi bem, vc tá usando o browser pra abrir um documento, certo? Via AppletContext?
Então vc chama lá o openDocument() ( ou sei lá como chama o método) e o browser devolve o controle pro applet, abrindo o documento sozinho. É isso mesmo?
Se for isso, não dá pra fazer nada, porque a nova thread não está na JVM.
Se não for isso, explica como funciona seu applet que a gente cava a resposta!!
te+!!
|
|
|
|
Pergunta pra Patrícia se funcionou adicionar um AdjustmentListener.
Pegar o scrollbar vc sabe, né?? Deve ter algum método no JComboBox.
Eu tenho uma dúvida... vc tentou mudar o BoundedRangeModel que está associado ao JScrollBar?? Quem sabe reimplementando o model vc não precise pegar cliques, e tal... tudo funciona automaticamente...
boa sorte!!1
|
|
|
|
Olá, Emerson.
O Swing é implementado em cima da AWT; a AWT é um ESQUEMA de implementação de widgets. Até aí tudo bem.
Mas o que nem todo mundo sabe é que a awt é plugável!! Sim, mudando uma System Property vc pode escolher qual implementação de AWT vc quer usar.
A implementação da Sun usa o SO para desenhar retângulos e fazer blitting (somar matrizes de pixels de forma a sobrepor desenhos).
Uma outra implementação de AWT é a tal PJA Toolkit:
www.eteks.com/pja/en/
A grande vantagem é não precisar de um ambiente gráfico para manipular canvas. Vc continua não podendo abrir janelas, mas pode, por exemplo, ler o conteúdo de um JPEG.
a PJA, até onde eu sei, não funciona com o jdk 1.4 ainda. Mesmo assim, acho que no JDK 1.4 a Sun enxugou ao máximo o quanto de SO é necessário. Acho que eles tão no esquema "aproveita se tiver, se vira se não tiver" (try once, do it anyway).
aquelão!!
|
|
|
|
Quanto às interfaces... uma classe que implemente ambas simplesmente não compilará...
Ah, meu caro Carlos... vc já tentou?? Experimente... vc vai ficar assim:
O Leandro reparou certo: o Morcego tinha dúvidas entre usar uma interface ou uma classe abstrata... mas quando é necessário usar uma classe abstrata??
Todas as vezes que eu usei uma classe abstrata, eu estava usando um padrão chamado Strategy: quando vc permite ao sistema ter várias formas de fazer um processo através de subclasses que implementam de forma diferente um mesmo método. No exemplo do Dango tinha um método getJuros();
Pense no imenso cálculo que envolve fazer o imposto de renda. Eu poderia criar uma classe com o método abstrato calculaIR(double salario) implementando todo o resto e deixando cada subclasse fazer a própria conta. (Claro que esse não é um exemplo real).
Desse jeito, vc escolhe sua estratégia com as subclasses, mas usa polimorfismo para garantir que todos os seus objetos sabem calcular seu próprio IR. Daí o nome do padrão.[/b]
|
|
|
|
Vc já viu como funciona o Acrobat Reader? É um exemplo meio ruim, pq não é muito claro como funciona, e ele tenta copiar o Word e acaba não funcionando direito.
Minha cara Patrícia, vc está brincando com fogo. Alterar o comportamento de coisas bem conhecidas pode deixar seu usuário muito desorientado. Além disso, o trabalho pra implementar algo assim é muito maior. Como disse em outra discussão aqui, pense como isso ia funcionar se desse certo. Imagine um usuário usando seu PowerScrollBar, quais ações ele poderia fazer, e se os efeitos são coerentes.
Veja como funciona a classe javax.swing.BoundedRangeModel pra vc ver onde vc tá se metendo: talvez valha mais implementar seu próprio widget!! Digo isso pq se vc quer fazer paginação (é isso que vc quer fazer, certo?), vc pode criar um componente que seja uma lista (com scrollbar) e mais dois botões, um em cima, um embaixo, que signifiquem "página anterior" e "página posterior". Isso faz a navegação que vc deseja, com pouco trabalho a mais para o usuário.
Daí vc tem que imaginar uma forma de colocar isso como editor do seu componente (que provavelmente será um conjunto JLabel + JButton, mais ou menos como os ComboBoxes do HTML). Se vc achar uma boa idéia, eu posso colaborar com vc.
Se vc não gostou da minha idéia, olhe lá o BoundedRangeModel. Talvez fazendo uma subclasse dele vc consiga o comportamento que vc precisa sem correr atrás de cliques.
boa sorte!!
|
|
|
|
Legal... mas me conta seu objetivo maior... pra que vc quer saber quando o cara clica na setinha?? O que vc quer que o seu programa faça? Qual a esperteza que vc quer dar?
Eu chutaria que a setinha funciona mais ou menos como um botão que só manda eventos pro scrollbar. Vc tentou adaptar um AdjustmentListener pra ver o que ele imprime??
Abraços!!
|
|
|
|
Meu, interfaces surgiram no Java pra atender a uma necessidade na programação OO que em C++ é implementada de um jeito muito feio: herança múltipla.
A idéia é que vc tem uma classe Automóvel, abstrata ou não, não importa. Ela tem métodos de acesso aos dados típicos de um automóvel, por exemplo, quantos litros de gasolina tem no tanque, ou se ele está ligado.
Aí vc quer fazer herança pra usar polimorfismo (alguém tem um dicionário? :lol. Isto é, vc quer fazer as classes Carro e Moto sendo extensões de Automovel e aproveitando alguns métodos e reimplementando só o necessário. Polimorfismo significa que vc quer poder declarar uma variável da classe Automóvel no seu programa e atribuir um Carro ou uma Moto de forma que ele consiga chamar os métodos certos pras variáveis certas.
Agora vamos imaginar que no seu programa vc tb tem uma classe Patrimônio, abstrata ou não, que tem métodos como valorDeVenda(). Com certeza, se vc comprou um carro, ele é patrimônio seu, e vc quer modelar isso no seu programa. E agora, como a classe carro pode ser ao mesmo tempo Automovel e Patrimonio?
Em C++, eles resolveram do ponto de vista do compilador: pode ser as duas. O compilador se vira, e vc tem meios de fazer a coisa funcionar. Mas e em Java?
Em Java vc só pode ter uma classe pai, isto é, vc só pode extender 1 classe. Mas vc pode implementar várias interfaces. Assim é que eles permitem herança múltipla. Em vez de uma classe abstrata, vc declara uma interface Automóvel e uma interface Patrimônio. Sua classe Carro, concreta, pode implementar as duas interfaces e "ser vista" como Automóvel pelo código que mexe com automóveis e como Patrimonio pelo código que lida com seu imposto de renda.
Outras explicações mais filosóficas são uma tentativa de te enrolar. Ninguém nesse meio faz nada que não seja absolutamente necessário. Só nós que tamos aprendendo ainda... : )
Aliás, pra quebrar a cabeça: o que acontece quando duas interfaces diferentes têm um método com a mesma assinatura? E se mudar só o valor de retorno? Exempllo:
Quem manda na hora de escolher qual método vale?
abração!!
|
|
|
|
Minha cara patrícia, vamos com calma.
O que exatamente vc quer fazer? Descobrir se alguém mexeu no scrollbar? Ou vc precisa de mais do que isso? C quer saber se tá subindo ou descendo? Se é pra ir um só ou vários itens? Ouvir a ScrollBar é uma saída, mas provavelmente existem outras.
Eu sei que tem um esquema muito simples implementado na JScrollBar que é o AdjustmentListener:
A classe mesmo é java.awt.event.AdjustmentListener. Não sei se resolve o seu problema. Explique melhor onde vc quer chegar... é bem provável que exista uma solução pra ele.
te+!
|
|
|
|
|
|