| Autor |
Mensagem |
|
|
luiz_renato wrote:Renata,
Já que vc tem o Danfe , seria interessante com os dados dele vc gerar a chave de acesso e tentar fazer a consulta.
Não tem como. Um dos valores necessários para formar a chave é um tal "código numérico" que é uma sequência aleatória gerada no momento do envio da NF-e. Então não tem como eu montar a chave por não ter como saber o tal código numérico.
|
 |
|
|
Olá pessoas!!!
Seguinte, tenho uma maldita DANFE que por alguma zica está sem chave. O que eu queria era uma forma de consultar a nota no site da SEFAZ sem a chave, pra que eu consiga confirmar se deu alguma caca e o sistema não gravou a chave ou se a nota realmente não foi enviada. Foi uma nota de uma data que tivemos um problema de estrutura, agora tá tudo resolvido, não acontece mais, mas tem essa caca que sobrou aqui pra mim, tem cerca de 1 mês a nota.
O fato é que alguns estados brasileiros tem a opção de consulta da NFe sem ser pela chave (informando outros dados). Mas no caso do estado de SP eu juro que não encontrei. Alguém sabe se tem alguma forma?
Grata,
Renata
|
|
|
|
Não dá problema nenhum!
Aqui costumo fazer isso com tudo! Desenho as telas no NetBeans usando o Matisse, importo pro Eclipse pra programar os listeners e tudo o mais, inclusive rodar...
Confere os caminhos como o colega falou, veja exatamente qual é o erro que está dando pro seu colega.
|
|
|
|
Eles estão escritos exatamente da mesma forma (com maiúsculas/minúsculas)?
Dá uma conferida se por acaso não estão sendo encontrados por estar num escopo que não está acessível. Ou senão, se de repente eles estão estão declarados na classe principal da tela e vc está tentando acessá-los na classe do ActionListener.
|
|
|
|
Se vc souber, qual o número de "quebras" que precisará então realmente, apenas 2 agrupamentos e está tudo feito! 
Alias, pelo exemplo, tá parecendo plano contábil ou centros de custo, se for, é fácil, pq o número de quebras é fixo msm.
|
|
|
|
DaitonJr wrote:bom dia..
eu tenho um .jasper criado no ireport.. agora estou tentando importa para o ireport para fazer uma alteraçao..
so q quando abro da esse erro ' java.lang.classNotFoundException: nomedaclasse.scriplets'
alguem pode me ajudar pq nao tenho noçao do q seja?
Abra o seu .jrxml no iReport. Do lado esquerdo, no Report Inspector, vá em Scriptlets > REPORT. Ai do lado direito, no properties olhe o atributo "Scriptlet Class". Nesse atributo deve estar preenchido o caminho de uma classe usada como scriptlet pelo seu relatório. A impressão que dá pelo erro que vc mencionou é que ele não está encontrando a tal classe. Confere ai, vai ver o caminho está errado, ou o nome da classe mudou, ou vc não usa mais. Enfim, esse atributo é o "ponto de partida" pro seu probleminha...
|
|
|
|
Solução!!!!
Só pra ficar registrado aqui, pra quem precisar depois de mim.
Então entanglement, ele não força o redesenho da tela se a altura não for alterada, quero dizer, se eu não settar o valor. O problema era que eu estava settando!
Meu erro era MUITO simples, mas eu juro que não enxergava (e nem tinha como vc enxergar, pq não estava no trecho de código que eu postei).
Simples, invés de usar:
que seria o correto, inclusive vc postou desta forma.
Eu estava usando assim:
Desgraça do ctrl+space!!! Puxou o método errado e eu nem vi! E isso desde antes de eu postar aqui a primeira vez! Então ele sempre comparava minha altura com a altura padrão de linhas do JTable, e sempre lógico, precisava mudar denovo, o que fazia com q ele fizesse a renderização novamente,,,, e ai o loop que já falamos.
Perdi um tempão tentando encontrar quem era que chamava a renderização, pra tentar impedir, olhei cada método.... alias, segundo a API, é o próprio setRowHeight() que chama a renderização.
Enfim, acertei esse detalhe besta q eu não estava enxergando e pronto! Ele passa uma vez, na segunda ele já está com o valor alterado então não passa e tudo funciona!
Obrigada a quem me ajudou, e fica ai a dica pra quem precisar... rs...
T+,
Re
|
|
|
|
Não não... tudo isso que vc falou eu já trato.
Já verifico se a altura precisa msm ser mudada, já verifico a altura da maior célula da linha, tudo feitinho. É que só postei a linha em que eu de fato preciso alterar o tamanho. Tendeu?
E sim, como vc disse, o setRowHeigth está forçando o redesenho da tela.
Como fazer pra que ele não force?!
|
|
|
|
entanglement, consegui entender onde está a caca, mas não estou conseguindo resolver. Vou dar uma exemplificada pra vc entender como uso, quem sabe vc me dá uma dica de como resolver.
Qdo estou criando meu JTable e colocando tudo que preciso, coloco o renderer assim: (suponha que meuTable seja o JTable e meuRenderer seja um TableCellRendererPadrao)
O TableModel de meuTable, extends AbstractTableModel.
TableCellRendererPadrao é minha classe que extends DefaultTableCellRenderer, vou colocar a carcaça dela aqui pra vc ver:
Tá vendo a linha que eu marquei com um ATENÇÃO? Qdo eu dou esse comando, pra mudar a altura da linha, ele chama o Renderer, e o Renderer que tá dando esse comando, que chama o Renderer que dá o comando que chama o Renderer................. tendeu? Loop!!! De dentro do meu Renderer eu chamo o comando pra ajustar a altura da linha que justamente chama meu Renderer denovo! Por isso a loucura do Loop! Agora fez sentido tudo!!!
Agora me ajuda a resolver... pq assim, sei que é ai o problema, se eu comento, não fica em loop, não sobrecarrega processador, fica tudo certinho. Mas claro, não posso apenas comentar, pq preciso desse ajuste de altura nas linhas pra não ficar tudo esmagado.
Eu tentei, antes de dar aquela linha de comando que marquei com ATENÇÃO, remover os Renderes de todas as colunas do meu JTable, acionar o comando, e depois voltar os Renderes. Porém, sem sucesso, eu fiz exatamente o que te falei e mesmo assim entrou no tal loop. A impressão que dá é de que não adiantou eu remover os Renderes pq ele não chama já de imediato, ele espera terminar de montar todas as linhas que couberam na tela, pra depois chamar o Renderer pra todas denovo. E ai denovo, e denovo, e denovo.... (dei um "sysout" e é isso que ele faz, fica em loop com as linhas que eu estou na tela).
Alguma sugestão de como posso falar pra ele não refazer nesse caso?!
Grata,
Renata
|
|
|
|
Então entanglement, não uso o DefaultTableModel não. Tenho uma classe que extends o AbstractTableModel. Nela eu já trato coisas que eu preciso.
Vc mencionou que cada vez que chamo o setValueAt ele dispara o evento tableChanged e toda a JTable é redesenhada. Acho estranho pq eu não uso o setValueAt o tempo todo. Como falei, é uma tela de consulta, então eu faço o select no BD, adiciono o resultado no model do meu JTable usando addRow e só! Parei! Não mexo em mais nada nos dados, a não ser que o usuário especifique um novo filtro e mandei pesquisar novamente (ai eu limpo tudo e refaço o processo de pesquisa com o novo filtro).
Porém, notei que mesmo com a tela parada, sem mexer em nada, fica rodando o tal Renderer o tempo todo, e meu processamento vai pro céu!
Eu não conhecia os métodos "fireAlgumaCoisa". Vou tentar sobreescrevê-los na minha classe Model pra ver no que dá.
Vc tem alguma dica de como posso fazer esse tal controle?
Grata,
Renata
|
|
|
|
|
É então, era o que eu ía dizer... no remove vc tem que passar o Component e não o índice dele... Mas vc acabou achando sozinho!
|
|
|
|
Poxa amigo, me explica melhor o lance do "fireAlgumaCoisa" que eu não entendi.
Onde ele estaria chamando isso? Desculpe, mas não entendi msm. E o que vc disse parece ser bem plausível com a situação que estou enfrentando.
Grata,
Renata
|
|
|
|
lgweb wrote:Vixi coitado de vc ser obrigado a trabalhar com delphi, delphi e lixo, tenho nojo de programadores delphi!!!
Não fala assim! Delphi já me manteve por muitos anos!!!
Então pereiralp, acho doideira manter Delphi simplesmente pq a tendência nessa vida é usarmos tecnologias novas, e não nos prendermos a antigas (não que eu ache que ele não funcione, alias, tem coisa que ele faz que tenho ódio por não conseguir fazer com Java... mas enfim)
Agora, fazer o esquema de ter a tela Delphi chamando processos java é triste não é não? Eu no seu lugar já estaria mandando CV por ai... rs...
Infelizmente nunca usei o tal CORBA e não sei o que pode dar. A única coisa que fiz nesse sentido (pra um projeto da faculdade na época) foi fazer a tela em Delphi executar o jar do java. Mas acho que no seu caso seria muita coisa... não daria certo... 
|
|
|
|
Fábio, desculpe, estou com pressa nesse horário e não pude ver todo seu código... mas assim, pra "tirar" uma aba de um JTabbedPane costuma ser simples, apenas assim:
Tentou isso?
O que exatamente está "dando errado" qdo vc tenta fechar a aba?
|
|
|
|
Olá pessoal!
Demorei mas apareci! 
Seguinte, tenho uma classe MinhaTableCellRenderer que extends DefaultTableCellRenderer.
No método getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column), eu implementei coisinhas que preciso, aquelas conhecidas sabe? Mudar a cor, mudar o tamanho da linha, fonte, etc, etc...
Meu problema está no fato de que isso está elevando o processamento demais. Então por ex, suponhamos que eu abro o Gerenciador de tarefas do Windows e o uso de CPU está em 3% (com meu sistema aberto, tudo rodando). Ai eu abro uma tela que tem um JTable usando esse Renderer e adivinhem? O processamento vai pra 30%!!!
Tenho casos em que qdo mais de um usuário acessa a tal tela (via comunicação, TS por ex), o consumo de CPU do servidor de aplicação sobe até dar o topo e travar tudo.
Sei que o tal método getTableCellRendererComponent fica sendo chamado seguidamente enquanto o JTable está sendo apresentado. Coloquei um "sysout" dentro dele e é chamado seguidamente, o tempo todo.
Por acaso alguém tem alguma dica do que posso fazer pra continuar com meu JTable personalizado (com cores, etc, etc...) e reduzir esse processamento de CPU? Não tem como eu de alguma forma fazer as personalização das linhas só a primeira vez que ela for acessada? É um caso onde o conteúdo do JTable não vai ser alterado, ele é carregado uma vez e pronto, não muda, é uma espécie de consulta, ele não precisaria ficar renderizando o tempo todo.
Alguma dica?
Grata,
Renata
|
|
|
|
|
|