EMBarbosa

Por favor, ao invés de enviar um lote de eventos, carregue os eventos separadamente na lib.

Por favor teste com a DLL anexa. ACBreSocial32.7z Se por acaso não funcionar, preciso que teste enviando um arquivo evento por vez a Lib. Carregue um evento por vez e depois faça o envio.

Você não me respondeu:

Como assim em ambos? depois que uma exception é levantada, o processamento não cessa? A questão é que precisamos saber se o erro é gerado pela FastStringReplace ou não. Como é um arquivo confidencial e como já recebemos um outro arquivo, no momento não precisa enviar. Se precisarmos vamos pedir mais tarde.

Alysson, afinal, o seu problema é lavantado no copy ou na FastStringReplace? Boa tarde. Você chegou a debugar para ver onde exatamente é levantada a mensagem de erro?

Ah me desculpe... Eu confundi os componentes. O ACBrReinf não tem log mesmo. Estamos avaliando o problema.

@vanessa_sensatta, ainda ficou faltando o log do componente.

Pode ser interessante ler: http://www.felix-colibri.com/papers/oop_components/delphi_virtual_constructor/delphi_virtual_constructor.html

Eu não me lembro dos detalhes, mas acredito que isso tenha relação com as decisões lá no início da linguagem. Bom eu lembro do seguinte: No Delphi/Lazarus, o "Constructor" sim nesse caso... Mas isso funciona com todos os métodos... Por exemplo, sua classe TPai poderia ter uma "procedure FooBar" e a TFilho também ter esse método. Eles não precisam ser necessariamente virtuais. A natureza do "Constructor", é ser um método da Classe, não do Objeto. Sendo assim, é esperado ele ser chamado na classe... Por exemplo o seguinte código gera uma AV: var umPai: TPai; begin umPai := umPai.Create; //O código correto seria da classe: umPai := TPai.Create; Já no Destructor isso não acontece. Ninguém chama "TPai.Destroy". Na verdade, se você notar seu código, você chamou o método "Free". Esse método "Free" não é virtual. Isso não explica plenamente sua dúvida, mas dá uma ideia do funcionamento... ou pelo menos mais coisas pra você pesquisar

Verifique se a mensagem é realmente da sua aplicação e não de outra que roubou o foco. Se for de sua aplicação, então em algum lugar está habilitado a "ajuda de contexto" (context-sensitive help). Bastaria desabilitar isso.

Synopse mORMot

Boa noite, Você está tentando enviar em "produção" ou em "produção restrita" (homologação)? Como está a configuração do componente na questão de versão? Está correta? Por favor, caso exista, anexe o log do componente gerado nessa tentativa.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 28031. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Olá. Nós geramos uma nova Lib do eSocial. É possível que ela resolva o seu problema. Mas tem um pré-requisito para que funcione. A dll deve estar configurada corretamente para possível assinatura. Então, queira por favor fazer o download e testar com ela. Mas não esqueça de fazer as configurações do certificado como fez antes. Também por favor, coloque o nível do log da Lib como paranoico. Assim caso gere algum erro, anexe aqui por favor o Log e os arquivos utilizados.

Boa tarde, tudo bem? A lib do eSocial é bem recente, e assim como nossos componentes está em constante desenvolvimento. Não tivemos ninguém que precisou implementar todos os eventos por meio de leitura de XML, e muito menos um xml de lote de eventos. Isso explica, o motivo de você ter encontrado essa situação. Bom o que eu notei no momento é a libxml2.dll (que é a dll de terceiros usada para ler o arquivo) não está conseguindo fazer o parse do seu arquivo. Parece que é na hora da leitura e não na hora de gerar o lote. Afinal, se funciona com o arquivo INI, a geração do Soap deveria ser semelhante. Estou tentando descobrir exatamente o problema do erro. Assim que tiver novidades retornamos.

Olá pessoal! Com muito prazer anunciamos que foi enviado hoje cedo ao SVN mais uma nova implementação de leiaute para o Reinf. A versão 2.1. Queremos agradecer de coração ao nosso moderador @Renato Rubinho que trabalhou nessa alteração. Como sempre fiquem atentos as novidades, logo liberaremos os ajustes para o ACBrMonitor. Também, se encontrarem qualquer problema, como sempre criem tópicos no fórum para relatar. Bom trabalho a todos!

Muito obrigado. Assim que possível vamos dar um retorno. Enquanto isso, você pode utilizar aquela outra maneira de passar um buffer bem maior para poder pegar todo o retorno.

Me mande esse log por favor. Só o log.

Entendi. As libs de modo geral tem esse funcionamento. Se você vai utilizar o método Lib_UltimoRetorno, não precisa inicializar as variáveis tamanho e resposta com um valor. A ideia é chamar o método da Lib, e depois redimensionar a variável resposta pro tamanho recebido. Daí, passar essas variáveis para o método Lib_UltimoRetorno. O código pode ser algo como o abaixo. Desculpe os possíveis erros, não sou programador Harbour. nLen := -1 ; <-- Aqui eu não sei ainda o tamanho da resposta cBuf := '' ; <--- string vazia ... IF (nRet := eSocial_ConsultareSocial(::hDll,Alltrim(oRec:protocolo), @cBuf, @nLen)) == 0 IF nLen > STR_LEN cBuf := Space(nLen) ; <-- agora eu aloco memória para receber o retorno... eSocial_UltimoRetorno(::hDll, @cBuf, @nLen) ENDIF ENDIF Verifique por favor se assim funciona.

No Lazarus, quando eu digito: self.Cap O editor pergunta se eu quero dizer Caption e eu aperto ENTER. A configuração padrão para completar é compacta: self.Caption:= Eu prefiro um espaço antes e depois do símbolo de atribuição: self.Caption := 'text' A configuração fica aqui: Fonte: https://forum.lazarus.freepascal.org/index.php/topic,61456.0.html

Me parece que agora, é a definição do tamanho da resposta que está ocasionando esse problema. Vamos fazer mais um teste, por favor: Mantenha o log como paranoico, mas volte o código seu como estava. Daí, execute novamente para gente poder verificar a diferença.

Você pode por favor alterar o nível do log para paranoico, e fazer a seguinte alteração no seu código? nLen := 1024 cBuf := Space(nLen) IF (nRet := eSocial_ConsultareSocial(::hDll,Alltrim(oRec:protocolo), @cBuf, @nLen)) == 0 IF nLen > STR_LEN cBuf := Space(nLen) eSocial_UltimoRetorno(::hDll, @cBuf, @nLen) ENDIF ENDIF Preciso comparar os retornos com o que estou reproduzindo aqui.

Que estranho... Deixa eu analisar seus arquivos novamente. Me parece correto. Qual sua linguagem mesmo?

Oi Bom dia. Enviamos uma alteração que deve resolver esse problema. Queira por favor testar com as novas dlls geradas hoje.

Verifique o Manual do Desenvolvedor versão 1.12.