Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Regras e orientações da nossa comunidade Participe do Discord do ACBr

Nelson A Sousa

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    351

  • Registro em

  • Última visita

  • Days Won

    1

 Tipo de Conteúdo 

Posts postados por Nelson A Sousa

    [AcbrNFeLib] - Pasta dos schemas

    em ACBrLIB

    Postado

    Olá Rafael, 

    Obrigado pela resposta!

    Acabei descobrindo que o erro estava na declaração da LIB.

    antes, funcionava corretamente e eu declarava assim:

                    _AcbrNFe = new ACBrNFe(NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini");

    agora precisei mudar para:

                    _AcbrNFe = new ACBrNFe(NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini","");

    veja que tive que inserir o segundo parâmetro como string vazia. Antes isso não era necessário para iniciar o constructor!!

    Agora, uma vez que o INI está sendo localizado, a pasta de schemas configurada também foi localizada corretamente.

    Verifiquei também que, mesmo agora, está sendo criado um segundo INI com dados padrão, na pasta raiz do EXE.

    ACBrLib.ini ACBrLibNFE-20200210.log

    • Curtir 2

    [AcbrNFeLib] - Pasta dos schemas

    em ACBrLIB

    Postado

    Olá, bom dia!

    Estou utilizando a AcbrNFeLib com C# no VS2019.

    Em meu arquivo AcbrLib.INI a pasta dos schemas está configurada como:

    PathSchemas=C:\MeuSistema\Schemas\

    Acontece que ao validar... _AcbrNFe.Validar();  está retornando o erro de que os schemas não foram encontrados, só que o path,  no erro, está descrito como na pasta raiz do executável:

    "C:\Projetos\...\...\Bin\Debug\Schemas\"

     

    Será que esqueci de algo?

    [AcbrLib] - Uma sugestão para os Enuns

    em ACBrLIB

    Postado

    .Olá pessoal,

    Gostaria de deixar uma sugestão para deixar a visualização dos enuns mais amigável.

    Para carregar numa combobox: 

    //No c# com XAML
Private void CarregaNFeLayoutDanfe()        
{            
	CboNFeLayout.ItemsSource = NgListaEnum.ListarEnum(typeof(TipoImpressao));            
	CboNFeLayout.DisplayMemberPath = "Value";            
	CboNFeLayout.SelectedValuePath = "Key";            
	CboNFeLayout.SelectedValue = TipoImpressao.tiRetrato;        
}

//No C# WinForms
        private void CarregaNFeLayoutDanfe()
        {

            CboNFeLayoutDanfe.DataSource = NgListaEnum.ListarEnum(typeof(TrNFeLayoutDanfe));
            CboNFeLayoutDanfe.DisplayMember = "Value";
            CboNFeLayoutDanfe.ValueMember = "Key";
            CboNFeLayoutDanfe.SelectedValue = TrNFeLayoutDanfe.Normal_Retrato;

        }

    Dessa forma os enumeradores assumem a descrição escolhida.

    TipoImpressao.cs NgListaEnum.cs

    • Curtir 2

    [AcbrMonitorPlus] - Pasta padrão EnviarEmailEvento

    em ACBrMonitor PLUS

    Postado

    Olá,

    Bom dia!

    Ao utilizar o método EnviarEmailEvento() eu informava apenas o nome do XML do evento sem o path, por exemplo:

    "35XXXXXXXXXXXXXXXX550010000000050000000058-ProcEventoNFe.xml"

    O monitor se encarregava de completar o path.

    Como este procedimento é muito pouco utilizado, hoje notei que está completando o path só que com a pasta padrão ..\Envios\.

    Só que, no caso deste cliente, ele alterou o path no monitor para C:\Methodus\Gerente\NFe\Enviados\Autorizados\Eventos, salva no AcbrMonitor.INI

    Para resolver tive que informar o path completo do xml do evento.

    Parece que o recurso do Monitor de completar o path não está respeitando o path salvo na guia diretórios.

    Como eu disse, eu já resolvi informado o path completo, só estou relatando para o caso de uma possível correção.

    • Curtir 1

    [AcbrLibETQ] - Demo c# - Constructor da classe invertido

    em ACBrLIB

    Postado

    Olá, Bom dia!

    Creio que a decisão na abertura do constructor está invertida na classe AcbrETQ.cs:

    Está assim: 

            public ACBrETQ(string eArqConfig = "", string eChaveCrypt = "") :
            base(Environment.Is64BitProcess ? "ACBrETQ32.dll" : "ACBrETQ64.dll")
        {
            var inicializar = GetMethod<Delegates.ETQ_Inicializar>();
            var ret = ExecuteMethod(() => inicializar(ToUTF8(eArqConfig), ToUTF8(eChaveCrypt)));

            CheckResult(ret);
        }

    Creio que deve ser invertida as posições de

    ? "ACBrETQ32.dll" : "ACBrETQ64.dll"

    para 

    ? "ACBrETQ64.dll" : "ACBrETQ32.dll"

     

    • Obrigado 1

    Imprimir Canhoto na NFCe

    em ACBrMonitor PLUS

    Postado

    Em ‎18‎/‎10‎/‎2019 at 16:40, josadac disse:

    Boa tarde Juliana,

    Esse relatório eu teria que desenvolver ou nas versões mais recentes do ACBr já possui essa funcionalidade ?

    É um sistema antigo, desenvolvido em Clipper, a ferramenta praticamente não tem recurso para impressão em modo gráfico.

    Grato.

     

    Sistema antigo em Clipper e já com NFce?!?!

    [AcbrLib.NFe] - Problemas no carregamento da Dll

    em ACBrLIB

    Postado

    13 minutos atrás, Rafael Dias disse:

    para resolver isso é simples.

    1. Você pode distribuir as dll corretas de acordo com o OS do seu cliente, o que é muito simples.
    2. Modificar a classe para carregar das pastas como você fez na mensagem
    3. Copiar as dll corretas nas pasta do windows.

    Qualquer uma das opções acima funciona corretamente, não tem necessidade de mexer na lib.

    Olá @Rafael Dias,

    Obrigado pela resposta.

    Quanto a sua sugestão 1, eu entendi. Eu só prossegui no post, para o caso de não se saber a OS do cliente, ou no caso de um cliente com várias máquinas com vários OS's. 

    Então, para não ter que ter várias versões de distribuição, eu pensei em termos apenas uma distribuição que atendesse qualquer tipo de OS.

     

    Quanto à sugestão 2 e 3, eu fiz exatamente isso. Modifiquei a classe e ela carrega as dlls nativas na respectiva pasta da OS.

    Nos testes que efetuei aqui, o funcionamento correto só ocorre quando as dlls de dependências estão na raiz do EXE. Note que falei das dependências, neste caso, quando aciono a LibNFe ela não busca na pasta configurada na  classe de alto nível, mas sim na pasta raiz do EXE.

    Não sei se estou explicando corretamente...rsrsrs...mas a questão está no carregamento das dlls de dependência.

    • Curtir 1

    [AcbrLib.NFe] - Problemas no carregamento da Dll

    em ACBrLIB

    Postado

    Minha limitação no Delphi não vai permitir que eu faça muita coisa não.

    O problema é que as dlls nativas do AcbrLibNFe, não importa a plataforma se x86 ou x64, sempre procuram as dlls dependências na pasta raiz do EXE.

    Como as dlls da pasta dep, apesar de terem o mesmo nome, são de plataformas diferentes e não podem ser copiadas para a pasta raiz do EXE.

    Para o carregamento das dlls nativas, no caso a ACBrNFFe32.dll e a AcbrNFe64.dll, cada uma em sua respectiva pasta de plataforma, tudo transcorre normalmente. Somente o carregamento das dependências é que não funciona.

    Como eu disse, meu conhecimento de Delphi é bem limitado, talvez alguém consiga fazer com que as dlls nativas procurem suas dependências na pasta da própria dll e não na raiz do EXE. Dessa forma poderemos construir um único instalador, já com as versões das duas plataformas x86 e x64.

    Para exemplificar coloquei a estrutura de pasta ideal na primeira imagem abaixo. Na segunda imagem coloquei a pequena modificação que precisei fazer no constructor da classe. Apenas acrescentei o path das pastas.

    Reparem que as dlls de dependência, apesar de plataformas diferentes, têm o mesmo nome. Isso impede a colocação das mesmas na pasta raiz do EXE, ou se coloca x86 ou se coloca x64. O que torna a verificação de plataforma executada no constructor da segunda foto, de certa forma inútil.

    acbrLib.jpg

    constructor.jpg

    [AcbrLib.NFe] - Problemas no carregamento da Dll

    em ACBrLIB

    Postado

    4 horas atrás, Daniel Simoes disse:

    Isso pode não funcionar muito bem em outras linguagens, como Java, VB... etc...

    Bom, sobre o  Java eu não posso falar.

    Mas quanto ao  C#, VB e VB.net não tem problema não.

    Vou  fazer umas modificações eu mesmo aqui, e, se der certo, eu envio pra averiguação.

    • Obrigado 1

    [AcbrLib.NFe] - Problemas no carregamento da Dll

    em ACBrLIB

    Postado · Editado por Nelson A Sousa

    @Daniel Simoes,

    Sim, e que as dlls nativas reconhecessem a mesma estrutura de pastas quando do carregamento das dependências.

    A raiz no caso seria a pasta AcbrLib, esta sim, seria colocada na pasta do executável.

    Uma vez que a classe de alto nível reconhecesse a plataforma em que está o EXE sendo utilizado. A estrutura de pastas seguiria uma padronização como a sugerida acima.

    Dessa forma não importaria a plataforma, se x86 ou x64, e o Acbr rodaria sem problemas.

    MONITOR GERA SOMENTE UMA PARCELA

    em ACBrMonitor PLUS

    Postado

    53 minutos atrás, slifebr disse:

    ja resolvi... 

    Olá,

    É uma boa compartilhar a solução com os demais usuários. Alguém pode estar passando ou passar pelo mesmo problema.

    Dê uma breve descrição do que estava fazendo errado e como solucionou!!

    Fica a dica!!

    Um Abraço,

    • Curtir 1

    [AcbrLib.NFe] - Problemas no carregamento da Dll

    em ACBrLIB

    Postado · Editado por Nelson A Sousa

    9 horas atrás, Daniel Simoes disse:

    Mas o tópico nos faz pensar... talvez o @Rafael Dias conheça uma maneira de manter o binário compatível com ambas versões de plataforma...

    Sim, um bom exemplo pode ser encontrado no carregamento da SqlServerTypes.

    Só que no caso, será necessária uma mudança nas dlls nativas,, elas que vão decidir em qual pasta procurar as dependências. Ou então, uma mudança geral em como arquivar as dlls nativas do Acbr, ou seja, separadamente, cada uma na pasta de sua respectiva plataforma.

    Mas essa segunda opção aí talvez seja necessária somente como forma de organizar os arquivos. Não tem tanta necessidade.

    Loader.cs

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.