[ACBrLib.Core] - SERIAL - enumeradores de velocidade e databits

[Nelson A Sousa]

Olá pessoa,

Bom dia!

Na AcbrLib Core serão criados enumeradores para as velocidades e databits da seção SERIAL?

Ou deveremos informar os valores?

[Daniel Simoes]

Creio que o @Rafael Dias, irá criar... porém ele está afastado por problemas de saúde...

Se desejar implementar, e anexar os fontes, podemos avaliar e subir para o SVN...

[Nelson A Sousa]

Olá @Daniel Simoes,

Obrigado pela resposta.

Segue anexo os enuns. Não sei se os nomes estão nas regras do Acbr.

Não sei se devo abrir outro tópico mas, já que estou trabalhando nas configurações do INI, lá vai:

 

1 - Tenho notado que as configurações do arquivo INI da lib , às vezes não salvas informações.

Notei que, se declarar  o constructor, por exemplo, apenas da AcbrPosPrinter, no arquivo INI só são criadas as seções e chaves correspondentes à PosPrinter.

Porém, para que todas as chaves do meu interesse sejam criadas, eu declaro vários contructors: AcbrNFe, PosPrinter, ETQ, etc....

Aí é que tenho notado que algumas informações são salvas e outras não no INI.

Uma vez que tenho tratado as configurações numa única tela, pelo que parece ao executar o ConfigGravaValor() informações estão sendo sobrescritas.

 

2 - A LIB insiste em trabalhar com um INI na raiz do EXE, mesmo eu informando o path para inicialização. No path que informo eu já tenho um INI com todas as seções e chaves, porém a lib cria um novo na raiz do EXE.

 

 

SerialBaud.cs SerialDataBits.cs

[Daniel Simoes]

3 horas atrás, Nelson A Sousa disse:

2 - A LIB insiste em trabalhar com um INI na raiz do EXE, mesmo eu informando o path para inicialização. No path que informo eu já tenho um INI com todas as seções e chaves, porém a lib cria um novo na raiz do EXE.

Consegue reproduzir esse comportamento com o Demo ?

Como devemos chamar inicializar a Lib, para que esse problema ocorra ?

[José M. S. Junior]

Boa tarde @Nelson A Sousa, vamos adicionar... 

Precisou modificar a classe ACBrDevice.cs também? Se possível adicione todas classes modificadas.

[Daniel Simoes]

3 horas atrás, Nelson A Sousa disse:

1 - Tenho notado que as configurações do arquivo INI da lib , às vezes não salvas informações.

Acho que o problema... é que a Lib salva as configurações na memória, para o Disco, sem verificar se o arquivo em Disco, recebeu modificações...  Vamos pensar em uma maneira de corrigir isso..

[Nelson A Sousa]

3 minutos atrás, Daniel Simoes disse:

Acho que o problema... é que a Lib salva as configurações na memória, para o Disco, sem verificar se o arquivo em Disco, recebeu modificações...  Vamos pensar em uma maneira de corrigir isso..

Deve ser isso mesmo, ao se declarar vários constructors para cada LIB do Acbr, uma cópia do INI vai pra cada. Daí na hora de salvar sobrescreve.

Creio que, por se tratar de um arquivo nem tão grande assim, o INI das configurações poderia ser criado com a totalidade das seções e das chaves, não importando qual LIB se use.

Dessa forma, ao se lidar com as configurações do mesmo, a declaração de apenas um constructor seria suficiente.

[Nelson A Sousa]

10 minutos atrás, José M. S. Junior disse:

Boa tarde @Nelson A Sousa, vamos adicionar... 

Precisou modificar a classe ACBrDevice.cs também? Se possível adicione todas classes modificadas.

Olá, @José M. S. Junior,

Obrigado pela resposta.

Não modifiquei nada na AcbrDevice.cs  porque esbarrei justamente no problema de salvamento do INI.

Da forma como construí minha rotina de configurações, eu pensei em tratar tudo no mesmo formulário. Porém com a questão de estar sobrescrevendo o INI e não salvando as configurações que modifico, não consegui progredir.

Fiz algumas alterações na velocidade da AcbrPosPrinter e não consegui efetivar as mesmas. Nem mesmo o arquivo de LOG foi gerado.

Como sou sozinho por aqui e tive que fazer uns atendimentos, não pude trabalhar no problema agora à tarde. Mas vou dar uma mexida hoje à noite e ver o que descubro.

23 minutos atrás, Daniel Simoes disse:

Consegue reproduzir esse comportamento com o Demo ?

Como devemos chamar inicializar a Lib, para que esse problema ocorra ?

Eu inicializo dessa forma:

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

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

[Nelson A Sousa]

Vejam que modifico a velocidade da posprinter pra 1200, modifico a impressora pra daruma, etc..., mas sempre carrega os valores padrão.

ACBrLibNFE-20200316.log

Vejam o que carrega na imagem abaixo.

Só não reparem na distribuição dos campos na tela, ainda estou construindo...rsrsrsrs

Editado 16 Março, 2020 por Nelson A Sousa

[Nelson A Sousa]

Só pra feito de teste, nos exemplo acima eu declarei todos os constructors que necessito, mas pra salvar eu usei apenas o do posprinter.

[Nelson A Sousa]

Pessoal, 

Acabei descobrindo o problema.

Quando a LIB lê o arquivo INI ela faz a leitura na pasta conforme eu declaro:

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

Porém quando ela salva, o salvamento é feito na pasta raiz do EXE.

Fiquei num loop quase sem fim por aqui...rsrsrsrs.

Notei também que as configurações de núcleo (GERAIS), por exemplo, os dados do emissor, não estão sendo salvas. Não importa qual LIB se use.

 

[José M. S. Junior]

11 horas atrás, Nelson A Sousa disse:

Notei também que as configurações de núcleo (GERAIS), por exemplo, os dados do emissor, não estão sendo salvas. Não importa qual LIB se use.

Bom dia, está realizando os testes com o Demo ACBrLibNFe também?

[Nelson A Sousa]

2 horas atrás, José M. S. Junior disse:

Bom dia, está realizando os testes com o Demo ACBrLibNFe também?

Bom dia!

Sim, estou usando a Demo C# da AcbrLib.NFe, AcbrLib.ETQ, AcbrLib.CHQ e a AcbrLib.PosPrinter.

[Nelson A Sousa]

Vou passar um passo a passo do que estou fazendo:

1 - Faço a construção:

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

Após a construção a AcbrLib.INI é criada na pasta que eu indiquei, veja abaixo o arquivo AcbrLib_Criada.INI.

2 - Faço as alterações, pra efeito de teste, alterei apenas o baud da PosPrinter pra 1200 e a impressora para Daruma:

                _AcbrNFe.ConfigGravarValor(ACBrSessao.Emissor, "RazaoSocial", _empresa.Empresa);  --> veja que envio a alteração Razão social com a AcbrNFe.

                _AcbrPos.ConfigGravarValor(ACBrSessao.PosPrinter, "Modelo", (ACBrPosPrinterModelo)CboModeloEscPos.SelectedValue); --> Aqui o comando de alteração da impressora.
                _AcbrPos.ConfigGravarValor(ACBrSessao.PosPrinter_Device, "Baud", (int)(SerialBaud)CboVelocidadeEscPos.SelectedValue); --> Aqui o comando de alteração do baud.

Finalizo tudo com:

                _AcbrNFe.ConfigGravar();
                _AcbrPos.ConfigGravar();
nesta mesma sequência.

A AcbrLib.INi é mantido na pasta que eu informo, veja arquivo abaixo (AcbrLib.INI_Mantida).

E por fim, é criado na raiz do EXE outro AcbrLib.INI com as alterações (AcbrLib_Apos_Alteracoes).

Infelizmente  o log não foi criado!!

ACBrLib_Criada.ini ACBrLib_Mantida.ini ACBrLib_Apos_Alteração.ini

[Nelson A Sousa]

Fiz um segundo teste alterando as posições de:

_AcbrNFe.ConfigGravar();
_AcbrPos.ConfigGravar();

para:

_AcbrPos.ConfigGravar();

_AcbrNFe.ConfigGravar();
               

e o resultado está no arquivo anexo.

Parece que a lib que lida de forma mais completa com o INI é a AcbrLib.NFe, pois alterou os dados gerais, etc. Porém ignorou as alterações da PosPrinter.

O @Daniel Simoes matou a charada lá em cima, cada LIB carrega uma cópia do INI para a memória e salva sem consultar o disco. A solução para isto é até simples, basta construir-alterar-salvar cada LIBde forma separada, mesmo dentro do mesmo formulário, ou seja, usar métodos com declarações privadas.

O problema que restou é que a leitura do INI é feita na pasta que informamos, e a gravação na raiz do EXE.

Acho que é isso...rsrsrsrs

ACBrLib_Segunda_Alteracao.ini

[Daniel Simoes]

@Nelson A Sousa,

Apliquei uma possível correção, nos fontes do SVN... Commit [r19423]

Citar

--- ACBrLibConfig ---
[*] Ajuste para que os métodos TLibConfig.GravarValor e TLibConfig.LerValor,
    verifique se houve modificações no arquivo de Configuração no Disco, antes
    de processar o novo valor
    (por: DSA)

 

3 horas atrás, Nelson A Sousa disse:

O problema que restou é que a leitura do INI é feita na pasta que informamos, e a gravação na raiz do EXE.

Como posso reproduzir o problema ?

o Nome do arquivo INI é atribuído geralmente em "LIB_Inicializar"... você muda ele de alguma outra maneira ?

[Nelson A Sousa]

55 minutos atrás, Daniel Simoes disse:

@Nelson A Sousa,

Apliquei uma possível correção, nos fontes do SVN... Commit [r19423]

 

Como posso reproduzir o problema ?

o Nome do arquivo INI é atribuído geralmente em "LIB_Inicializar"... você muda ele de alguma outra maneira ?

Não mudo não @Daniel Simoes, eu faço a declaração:

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

 

Após isso uso apenas _AcbrNFe para realizar a leitura do INI e as alterações.

Para reproduzir o que faço aqui siga:

1 - Deleto (limpo) a pasta Debug da minha IDE.

2 - Deleto o AcbrLib.INI e todos os logs  da pasta NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini"

3 - Compilo meu sistema e abro a tela de configurações, no evento load() já faço as declarações de cunho global para a tela que abri:

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

4 - Vou até a pasta NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini" e verifico a criação do AcbrLib,INI. Que no caso é criado corrtamente.

5 - Vou até a pasta DEBUG(raiz do EXE) e verifico se foi criado um AcbrLib.ini. Neste caso NÂO É CRIADO!!!

6 - Faço alguma alteração qualquer usando a PosPrinterLib  e a AcbrNFeLib, no meu caso apenas selecionei o modelo como Daruma e coloquei o Baud como 1200.

7 - Vou até a pasta que indiquei ao declarar (NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini") e vejo que o INI não foi alterado.

8 - Vou até a pasta DEBUG (raiz do EXE) e vejo que foi criado um segundo AcbrLib.INI, este sim com as alterações, mas somente com as alterações da Lib que foi fechada por último.

Esse é o roteiro do que fiz para descobrir que apenas são salvas as alterações da última LIB fechada. E salvas na pasta raiz do EXE, não na pasta que informei.

 

[Nelson A Sousa]

Eu consegui um progresso aqui retirando o escopo das declarações para o formulário inteiro e restringindo ao escopo do método.

Por exemplo, como eu dividi o formulário de configurações dentro de um TABControl, eu usei o evento GotFocus() da TAB selecionada para ler os dados do INI e carregar os controles dentre desta TAB. Ao terminar de carregar todos os controles da TAB, eu finalizo a LIB que inicializei.

Para salvar os dados alterados dentro de cada TAB, eu utilizei o evento LostFocus() da mesma. Novamente eu inicializo a LIB, faço a gravação dos valores no INI com ConfigGravarValor(), e finalizo novamente a LIB inicializada.

Usando dessa forma, ou seja, inicializando, manipulando, e finalizando cada LIB dentro dos métodos, no caso GotFocus() para carga e leitura dos dados do INI, e, LostFocus() para gravação do INI, eu consegui salvar os dados.

Mas, ainda notei que sempre é criado um AcbrLib.INI na raiz do EXE, só que este contém apenas as seções e chaves da LIB que foi fechada por último.

Notei também que, para manipular os dados GERAIS, é necessário usar-se a AcbrLib.NFe, as outras que utilizei aqui, posprinter e ETQ não manipulam estes dados, apesar de criar o INI com os dados GERAIS padrão.

Ah, e como estou utilizando a demo do C#, eu tive que criar os métodos de finalização para que pudesse finalizar a LIB após sua utilização dentro do eventos.

        public void FinalizarNFe()
        {
            var method = GetMethod<Delegates.NFE_Finalizar>();
            var ret = ExecuteMethod(() => method());

            CheckResult(ret);
        }

 

[Rafael Dias]

Você deve estar fazendo algo errado, todas as libs manipulam os dados da parte geral, posprinter, SoftwareHouse, Emissor etc...

Totalmente desnecessário, note que as classes da lib implementam a interface IDisposable, bastando apenas chamar um dispose da classe que o método para desinicializar a lib será chamado.

Em resumo use só a lib nfe e configure tanto a NFe quanto o PosPrinter não precisa usar as duas libs juntas.

[Nelson A Sousa]

17 minutos atrás, Rafael Dias disse:

Você deve estar fazendo algo errado, todas as libs manipulam os dados da parte geral, posprinter, SoftwareHouse, Emissor etc...

Totalmente desnecessário, note que as classes da lib implementam a interface IDisposable, bastando apenas chamar um dispose da classe que o método para desinicializar a lib será chamado.

Em resumo use só a lib nfe e configure tanto a NFe quanto o PosPrinter não precisa usar as duas libs juntas.

Olá @Rafael Dias,

Eu acho que já testei com apenas uma LIB inicializada, mas vou repetir o teste pra sanar a dúvida.

[Nelson A Sousa]

@Rafael Dias,

Efetuei o primeiro teste utilizando apenas a AcbrLib.NFe, inicializei assim:

No escopo do formulário:        

private ACBrNFe _AcbrNFe;

 

No evento Load do formulário:

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

 

Apenas abri o formulário para a criação e primeira carga do INI e o que aconteceu foi:

Foram criados 2 AcbrLib.INI, um na pasta que informei na inicialização, e outro na raiz do EXE (pasta debug).

Apesar de terem o mesmo nome AcbrLib.ini, os dois tem conteúdo diferentes.

Quando faço a leitura do criado na inicialização a seção AcbrPosPrinter_Device e suas chaves não são encontradas. Porém veja que estão no INI criado na raiz do EXE.
 

ACBrLib_Raiz_do_EXE.ini ACBrLib_Pasta_Inicializacao.ini

[Rafael Dias]

Me passe um passo a passo de como reproduzir este erro usando o demo.

[Nelson A Sousa]

3 minutos atrás, Rafael Dias disse:

Me passe um passo a passo de como reproduzir este erro usando o demo.

ok, lá vai:

1 - Limpe tudo da raiz do EXE, no meu caso pasta DEBUG do minha IDE.

2 - Apague o AcbrLib.ini da pasta de inicialização, no meu caso NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini". Você tem que informar uma pasta diferente da raiz do EXE, ok?

3 - no escopo do formulário:  private ACBrNFe _AcbrNFe;

4 - no evento load do formulário:             _AcbrNFe = new ACBrNFe(NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini");
 

5 - Apenas abra o formulário e verifique se os arquivos AcbrLib.ini foram criados na pasta da inicialização e na raiz do EXE.

6 - Verifique o conteúdo dos arquivos, no meu caso tentei efetuar a leitura da seção PosPrinter_Device e ela não foi encontrada no arquivo da pasta da inicialização.

[Rafael Dias]

foram enviadas novas versões da dll favor testar com elas.

[Nelson A Sousa]

16 minutos atrás, Rafael Dias disse:

foram enviadas novas versões da dll favor testar com elas.

Ok, @Rafael Dias ,

Vou testar amanhã cedo!