Fala ai Galera blz? … vê ai se vcs podem me ajudar …
to com um problema com o Jtable … preciso enviar um valor
para o JModel de outro formulário e atualizar essa Jtable mas não
to conseguindo … já tentei de um monte de jeito e pesquisei aqui
no forum alguns tutoriais mas não consegui … é possivel atualizar
o DefaulTableModel e Jtable de outro formulário? …
opa errei ai no tópico acima onde eu escrevi JModel leiam DefaultTableModel
Primeira dica
NÃO use DefaultTableModel
Aprenda a implementar um TableModel de verdade que voce pode dar essas funcionalidades a ele.
Ah blz já consegui fazer … Valeu
Velhão… se poder lança o código pra galera e coloca RESOLVIDO no tópico!
[]'s
Se ele ainda está usando o DefaultTableModel, eu não colocaria resolvido, e sim [GAMBIARRA QUE RODA].
Aliás, é melhor manter o código bem escondido também, pois pode virar motivo de piada.
Consegui resolver implementando o TableModel, como
também utilizando o DefaultTableModel … depois eu coloco
o código …
Oi,
Se usar um DefaultTableModel é tão ruim assim, porque essa classe foi implementada :shock:
Eu sei que não devemos usar DefaultTableModel (pois é uma horrivel mesmo), só que sempre quando vou utilizar uma tabela, fico imaginando isso =P
Tchauzin!
Na verdade, acho que é uma das coisas que com o uso, ficou comprovado que era muito ruim, e agora a Sun não consegue se livrar mais dele, pois já tem uma base de usuários sofrendo com seu uso.
Acho que a Sun deve ser mais radical.
Arranca logo essa classe da API e leva junto a classe Vector.
Depois cria um jar chamado sei lá “nuke-bomb.jar” com as classes retiradas. E uma hora ou outra sua aplicação vai “explodir”.
Velhão… se poder dê um exemplo que possa “explodir” usando DefaultTableModel…
[]'s
Bom, só tem os seguintes motivos para não usar:
a) Misturar lógica de negócio com view, o que leva a um código confuso e difícil de manter;
b) Ocupar no mínimo o dobro de espaço;
c) Exigir mais processamento, já que são feitas cópias desnecessárias de objetos, conversões de string, etc;
d) Potencial para bugs por erros de casts (e isso pode levar a explosão);
e) Leite da geladeira azedando, esposa/marido te deixando, perda de emprego, cabelo caindo e ganho de peso. Ocasionado pela sua frustração ao manter seu próprio código.
Bom, só tem os seguintes motivos para não usar:
a) Misturar lógica de negócio com view, o que leva a um código confuso e difícil de manter;
b) Ocupar no mínimo o dobro de espaço;
c) Exigir mais processamento, já que são feitas cópias desnecessárias de objetos, conversões de string, etc;
d) Potencial para bugs por erros de casts (e isso pode levar a explosão);
e) Leite da geladeira azedando, esposa/marido te deixando, perda de emprego, cabelo caindo e ganho de peso. Ocasionado pela sua frustração ao manter seu próprio código.[/quote]
kkkkkkkkkkkk
Isso que faltava…um exemplo tangível 
[]'s