Jump to content

click.png  

 

 

 

 

 

Transforme seu banco de dados
em um app mobile!

botao_e_logo_plugmobile1.png

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Nelson A Sousa

Membros
  • Content Count

    244
  • Joined

  • Last visited

  • Days Won

    1

Nelson A Sousa last won the day on July 29 2018

Nelson A Sousa had the most liked content!

Community Reputation

75 Excellent

1 Follower

About Nelson A Sousa

  • Rank
    Membro
  • Birthday 05/17/1967

Contact Methods

  • Skype
    nelsonasousa

Profile Information

  • Sexo
    Masculino
  • Localização
    Muriaé - MG

Recent Profile Visitors

846 profile views
  1. .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
  2. Olá @José M. S. Junior, Obrigado pela resposta! Sim o path está gravado. O estranho é que está substituindo a pasta ..\Enviados\... pela pasta ...\Envios\... Acredito que para simular basta passar no parâmetro do xmlEvento apenaso nome do arquivo, sem o path.
  3. 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.
  4. 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"
  5. Olá @Rafael Dias, boa noite! Fiz um "revert" no arquivo (AcbrSessao.cs) e notei que a sessão DANFENFe agora também não está mais na classe. Tem outras pequenas correções no AcbrETQ, mas vou criar outro tópico pra não esticar muito aqui.
  6. Olá, Na classe AcbrSessao do demo c# da AcbrLib.Core tem um nome de sessão DANFECe. No arquivo INI eu encontrei como DANFENFCe. Há algum erro aí ou existem as duas mesmo?
  7. Pessoal, boa tarde! Estou criando um formulário de configurações para a AcbrLib. Na seção [DANFE] tem a TAG ImprimeCodigoEan e na seção [DANFENFe] tem a Tag ExibeEAN. Alguém pode me explicar a diferença entre as duas?
  8. Sistema antigo em Clipper e já com NFce?!?!
  9. 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.
  10. 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.
  11. 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.
  12. Admito que tem um certo grau de paranóia organizacional de minha parte...rsrsrsrs
  13. @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.
×
×
  • Create New...