ACBrNFSeX - erro "Resource ACBrNFSeXServicos not found"

[DatawebDev]

Recentemente foi feita uma alteração em TACBrNFSeX, que passou a chamar seu método LerCidades() em seu constructor. Isso quebrou compatibilidade com a nossa integração, e gostaríamos que revisassem a abordagem, ou a necessidade de chamar LerCidades() ao instanciar o componente.

O problema é que o LerCidades() depende da configuração do INI, feita em ACBrNFSeX.Configuracoes.Arquivos.IniServicos. Mas só se pode configurar o caminho para o arquivo INI depois de instanciar o componente.

Na nossa aplicação, o INI fica em %APP_DIR%\ACBr\NFSeX\ACBrNFSeXServicos.ini, enquanto o executável fica em %APP_DIR%. Até então, instanciávamos o componente, configurávamos o caminho para o INI, e depois chamávamos explicitamente o método LerCidades(). Com a alteração recente, ao chamar TACBrNFSeX.Create(), é chamado LerCidades(), que tenta ler o INI do diretório do executável, e como não existe, tenta ler o arquivo ACBrNFSeXServicos.res, que também não existe, e acaba gerando o erro

Resource ACBrNFSeXServicos not found

Poderiam reconsiderar essa abordagem de chamar o LerCidades() na criação do componente? Com ela, a configuração ACBrNFSeX.Configuracoes.Arquivos.IniServicos fica sem utilidade, porque não será usada por LerCidades(), que sempre buscará o INI do diretório do executável. Se for indispensável chamar LerCidades() para algum caso, poderiam fazer um overload no constructor, implementando um Create() alternativo que não chame LerCidades()?

[Diego Foliene]

32 minutos atrás, DatawebDev disse:

Recentemente foi feita uma alteração em TACBrNFSeX, que passou a chamar seu método LerCidades() em seu constructor. Isso quebrou compatibilidade com a nossa integração, e gostaríamos que revisassem a abordagem, ou a necessidade de chamar LerCidades() ao instanciar o componente.

O problema é que o LerCidades() depende da configuração do INI, feita em ACBrNFSeX.Configuracoes.Arquivos.IniServicos. Mas só se pode configurar o caminho para o arquivo INI depois de instanciar o componente.

Na nossa aplicação, o INI fica em %APP_DIR%\ACBr\NFSeX\ACBrNFSeXServicos.ini, enquanto o executável fica em %APP_DIR%. Até então, instanciávamos o componente, configurávamos o caminho para o INI, e depois chamávamos explicitamente o método LerCidades(). Com a alteração recente, ao chamar TACBrNFSeX.Create(), é chamado LerCidades(), que tenta ler o INI do diretório do executável, e como não existe, tenta ler o arquivo ACBrNFSeXServicos.res, que também não existe, e acaba gerando o erro

Resource ACBrNFSeXServicos not found

Poderiam reconsiderar essa abordagem de chamar o LerCidades() na criação do componente? Com ela, a configuração ACBrNFSeX.Configuracoes.Arquivos.IniServicos fica sem utilidade, porque não será usada por LerCidades(), que sempre buscará o INI do diretório do executável. Se for indispensável chamar LerCidades() para algum caso, poderiam fazer um overload no constructor, implementando um Create() alternativo que não chame LerCidades()?

Boa tarde!
Lamentamos que tenha ocorrido tal problema! Buscamos sempre manter os fontes do projeto ACBr compatíveis, mas as vezes é inevitável ocorrer alguma quebra.
A princípio a chamada do método LerCidades foi automatizada desta maneira pelo fato de muitos usuários estarem esquecendo de fazer a chamada manual ao método o que acabava acarretando em erros na hora de utilizar o componente.
Está melhoria também foi feita visando tornar o componente mais inteligente e mais próximo do padrão dos outros DFes.

@Italo Giurizzato Junior, por favor, o que acha desta sugestão do usuário?

[DatawebDev]

36 minutes ago, Diego Foliene said:

Está melhoria também foi feita visando tornar o componente mais inteligente e mais próximo do padrão dos outros DFes.

Obrigado pela rápida resposta Diego!

Sobre manter o padrão dos outros DFe, usamos o ACBrNFe da mesma forma, com o INI em outro diretório (%APP_DIR%\ACBr\NFe\ACBrNFeServicos.ini), e configurando seu caminho após instanciar o componente. E nele não temos esse problema.

Que tal manter o estado de "CidadesLidas" no ACBrNFSeX, e disparar exceção ao usuário, quando tentar usar um método que dependa das cidades, caso não tenha chamado o LerCidades()? A abordagem de chamar um método que dispara exceção no constructor pode acarretar em outros problemas também. Mas entendo a decisão de vocês, de tentar simplificar o processo.

[Diego Foliene]

30 minutos atrás, DatawebDev disse:

Obrigado pela rápida resposta Diego!

Sobre manter o padrão dos outros DFe, usamos o ACBrNFe da mesma forma, com o INI em outro diretório (%APP_DIR%\ACBr\NFe\ACBrNFeServicos.ini), e configurando seu caminho após instanciar o componente. E nele não temos esse problema.

Que tal manter o estado de "CidadesLidas" no ACBrNFSeX, e disparar exceção ao usuário, quando tentar usar um método que dependa das cidades, caso não tenha chamado o LerCidades()? A abordagem de chamar um método que dispara exceção no constructor pode acarretar em outros problemas também. Mas entendo a decisão de vocês, de tentar simplificar o processo.

A equipe do ACBr está analisando as possibilidades e pensando em possíveis maneiras de melhorar o uso do método, assim que tivermos novidade daremos um retorno aqui.

[Italo Giurizzato Junior]

Bom dia a todos,

Favor substituir as units por estas em anexo, reinstale o ACBr e façam novos testes.

ACBrNFSeX.pas

ACBrNFSeXConfiguracoes.pas

[DatawebDev]

Bom dia Italo! Desculpe a demora no retorno, estava ocupado.

Testei tua solução e funcionou! Muito obrigado.

[Italo Giurizzato Junior]

Bom dia Guilherme,

Vou ver com os demais membros da equipe para ver se não existe outra solução melhor, para que possamos enfim enviar para o SVN.

[Italo Giurizzato Junior]

Boa tarde Guilherme,

As Units que anexei acima para você realizar os testes, já se encontram no SVN.

[Italo Giurizzato Junior]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.