EMBarbosa

Em que momento aparece esse erro?

Me parece que está faltando configurações mesmo. Por exemplo: Testando no exemplo do ACBrNFSe, o layout não quebrou como quebrou na sua imagem. A primeira imagem que está faltando é a propriedade TACBrNFSeDANFSeRL.Logo. Atribua o caminho para um arquivo. A segunda imagem que está faltando é a propriedade TACBrNFSeDANFSeRL.PrestLogo. Atribua o caminho para um arquivo. Note que no seu exemplo, os dois logos são da NF-e, não da NFS-e.

Só pra confirmar, qual é o arquivo DANFSe que você utiliza?

Reabrindo esse tópico. O outro tópico já está fechado.

Me parece ok. Enviei ao SVN na revisão 15994. Queira por favor atualizar e verificar. Para esse problema queira criar outro tópico e me mencionar por favor.

Nesse caso tenho que concordar com o Henrique é realmente melhor você criar um tópico para cada problema. Você vai precisar exemplificar em cada tópico o problema que está passando e como reproduzir.

Moderação: Tópico dividido Se você debugar a aplicação, ela não dá nenhuma outra mensagem de erro?

Se houver alguma e não existir um tópico sobre ela, pode reportar aqui mesmo.

Já foram corrigidos esses problemas citados.

Pelo visto você está fazendo a certificação com ECF, correto? Você verificou se sua aplicação está dando o retorno correto ao ACBrTEFD sobre a situação do ECF? O que é apresentado nos logs do ACBrTEFD?

Esse tópico é para informar que o Refactoring das impressores DF-e foi concluído e enviado ao SVN na revisão 15983. Queremos lembrar que vai ser necessário reinstalar os pacotes e componentes, pois houveram alterações nas propriedades. Se você utiliza o ACBrInstall, não se preocupe. Ele já foi atualizado no SVN e daqui a pouco será já foi atualizado aqui na área de Downloads também. Se você não sabe do que se trata, veja esse tópico aqui: Nesse tópico são citados dois vídeos sobre o refactoring que recomendamos você assistir. Esse abaixo explica o refactoring: E esse mostra um exemplo de atualização de uma aplicação usando usando o exemplo do ACBrNFe: Deu bastante trabalho esse refactoring e fomos bem minuciosos. Mas pode ser que alguma coisa passou despercebido. Sugerimos que você atualize sua aplicação e comece os testes o quanto antes possível. Para complementar o disponibilizado antes, veja também essa tabela abaixo o nome de propriedades e métodos que mudaram. Note no entanto que há propriedades que são específicas de algumas classes e isso não foi alistado abaixo: Uma informação importante é que agora existe um componente específico para NFC-e em Fast Report. Se você vai trabalhar com NFC-e e imprimir usando o Fast Report, será necessário utilizar esse componente. Nele você encontrará as propriedades que são específicas para NFC-e. Agradecemos ao @BigWings pela ajuda no trabalho com esse componente. No mais, bom trabalho a todos.

O segundo vídeo mostrando um exemplo de como atualizar já está on-line. Vejam: A previsão é que até a tardinha já esteja no SVN os componentes já alterados.

Verifique primeiro se com o programa de exemplo funciona, por favor. Porque não me lembro desse problema. Pode ser que seu sistema esteja alterando a formatação de campos float do Windows.

Esse erro é diferente do apresentado nesse tópico. Apague o arquivo "SPEDFiscal.dproj" e tente novamente. Acabei de fazer o teste aqui no Berlim e abriu e compilou e executou sem erros.

O Régys fez uma alteração hoje agora a pouco. Confere aí.

Acho que não existe nenhum componente que faz isso. Talvez você deva pensar se não seria o caso de mudar para um outro estilo de GUI. Ao invés de usar SDI ou MDI usar TDI, por exemplo. Mas se quiser uma outra opção, você pode responder a mensagem WM_SYSCOMMAND do windows para detectar que ele está sendo minimizado e daí escondê-lo. Veja um exemplo em: https://stackoverflow.com/a/20575148/460775

É desse jeito mesmo que tem que ser feito. Infelizmente não existe um lugar só para procurar. Felizmente algumas UFs tem um site só sobre o SPED e facilita procurar legislação específica. O de MG é http://www.sped.fazenda.mg.gov.br/ Infelizmente, nem sempre estão atualizados, como é o caso de MG.

Crie na sua aplicação uma opção "gerar bloco K"?

Realmente, estou movendo para área apropriada. Não tem, mas talvez alguém possa ajudar. Como assim "minimizar o form e mover para o panel"? Poderia explicar melhor?

Se estiver em modo debug esse erro é comum... Ele geralmente é tratado pelo componente. Mas se você demorar a clicar em "Continue", o componente pode entender que a demora superou o TimeOut, daí vai retornar o erro. Então o certo é clicar rápido no botão, ou marcar para "ignorar esse tipo de exception".

pode ser necessário aumentar o timeout.

Legal! O mORMot é uma ferramenta muito poderosa e, na minha opinião, é ideal para o que está querendo fazer. Se começar a usar ele vai querer jogar fora os TDatasets. ? Realmente, você ter que alterar um código chamado milhares de vezes não é o desejado. Se não me engano a unit SynDBVCL.pas pode ajudar nessa conversão. Mas você precisa mesmo de um pouco de cautela. O que você colocar no componente IBXQuery e UniQuery em tempo de design, não vai funcionar em tempo de execução. Afinal, você mesmo admitiu que não está usando a conexão desses componentes. Quando você faz: Você substituiu a query desenhada em tempo de design, e consequentemente os campos (TFields) adicionados em tempo de design também param de funcionar. Um detalhe é que isso acontece toda vez que o comando acima for executado, cada vez apontando para uma referência diferente. O mORMot já tem uma função que retorna o Dataset preenchido. Se não me engano um TClientDataset. Veja esse post no blog deles, embora um pouco desatualizado, indica a unit que mencionei acima. A conexão sempre vai ser necessária, de uma maneira ou de outra, mesmo que por fora do TDataset. No seu caso, a conexão terá que ser feita pelo mORMot. Processar os dados manualmente e preencher um TDataset daria mais trabalho do que substituir o seu design atual. Eu não recomendaria isso de forma alguma. É preferível remover de vez os componentes em tempo de design e passar a usar só o mORMot. Com certeza daria um trabalho braçal agora, mas tornaria seu aplicativo muito mais clean, fácil de dar manutenção e com uma possibilidade de erros muito menor. A outra opção mais interessante que vejo é tentar fazer funcionar o proposto no começo: remapear todos os campos em tempo de design para os campos criados pelo mORMot. Note no entanto que você teria que fazer isso para cada query existente no seu datamodule e toda vez que a query for ativada. Ou seja, você teria criar um método que faz o mapeamento dos campos e substituir em todos os lugares que é executado comandos semelhantes aos abaixo: UniQuery1.Open; //ou UniQuery1.Active := True;

Moderação: Movido

Mas esse problema não é exatamente sobre a IBXQuery ou UniQuery. É sobre objetos e referência. Bom, em algum momento ele precisa se comunicar com o BD. Então a conexão precisa ser feita. A menos que estejamos falando de coisas diferentes aqui... Mas pelo que você mencionou anteriormente, a conexão funcionava. Veja o que você mesmo escreveu antes: Isso significa que aconteceu a conexão. É um pouco difícil orientar vocês porque não entendi muito bem o que vocês querem fazer nem sei qual é o framework que vocês estão utilizando para fazer o ORM.