I/O ERROR 103 após atualização ACBr em 2020

[aocampioni]

Pessoal,

Boa tarde. Notei um fatídico I/O error 103 após última atualização que fiz nessa semana, dia 10. Simplesmente não sei o que é, antes eu utilizava portas no sistema , mesmo com o ACBrPosPrinter ou com o famoso Rewrite dessa maneira: \\127.0.0.1\tp650 , tipo, impressoras compartilhadas em outras máquinas (claro que essa impressora é compartilhada mas tá local na minha máquina para testes) e agora obtenho esse erro;

Basta tentar ativar ou desativar que o erro é provocado. Pra simular certinho, entrei no posprinter demo, dei ativar e não ocorreu o erro. Desativei e selecionei Cortar Papel e fui ativar novamente e deu erro na Função abrir arquivo:

procedure TACBrDeviceLPT.AbrirArquivo;
var
  CreateModeFlag: Integer;
  NomeArq: String;
begin
  NomeArq := ObterNomeArquivo(fpPorta);

  if fsUsarStream then
  begin
    if IsTXTFilePort and FileExists(NomeArq) then
      CreateModeFlag := fmOpenReadWrite
    else
      CreateModeFlag := fmCreate;

    CreateModeFlag := CreateModeFlag or fmShareDenyWrite;
    // Tentando abrir o arquivo
    fsFileStream := TFileStream.Create(NomeArq, CreateModeFlag);
    fsFileStream.Seek(0, soEnd);  // vai para EOF
  end
  else
  begin
    AssignFile(fsArqPrn, NomeArq);
    if IsTXTFilePort and FileExists(NomeArq) then
      Append(fsArqPrn)
    else
      Rewrite(fsArqPrn);  =====> nessa linha dá o erro ao tentar ativar novamente.
  end;
end;

Não sei o que pode estar ocorrendo, agora nem os formulários que estão somente com o Rewrite funcionam. Passei todos os formulários de impressão para o PosPrinter mas ao ativar e desativar e ativar novamente dá esse problema do erro 103. Tentei usar o controle da porta mas o erro persiste. Interessante é, que se eu utilizar como USB:Tanca ou RAW:TANCA TP-650, local, o erro não acontece de forma nenhuma. Se a impressora compartilhada for detectada de forma local como RAW (caso da NPI0DE3D) o erro também não acontece.

Posso desativar, mudar opções, ativar e imprimir que o erro não acontece nesse caso. Será que alguma mudança no ACBrDevice fez isso? Antes não havia necessidade de utilizar ACBrDeviceSerial e agora tenho que utilizar senão dá alguns erros na compilação. Tenho uma máquina com uma versão anterior do trunk2 com o ACBrDevice sem a presença do ACBrDeviceSerial e lá, o erro não acontece em nenhuma das simulações que fiz.

Alguém tem alguma ideia do que pode estar ocorrendo ? 

Obrigado.

[Daniel Simoes]

Por favor seja mais específico...

Usando o Demo do ACBrPosPrinter... Qual o passo a passo, desde a execução do programa, até obter o erro ??

[Daniel Simoes]

Lembrando que você não precisa compartilhar impressoras Locais, para usar no ACBr... pode usar em "Porta"

"RAW:Nome da Impressora no Windows"

"USB"

 

[Daniel Simoes]

Por favor teste substituindo a Unit em anexo

 

 

ACBrDeviceLPT.pas

[aocampioni]

Daniel, boa noite. Muitíssimo obrigado pelas prontas respostas, vou substituir a biblioteca agora e testar. 

Retorno mais breve possível.

Até mais,

2 horas atrás, Daniel Simoes disse:

Por favor seja mais específico...

Usando o Demo do ACBrPosPrinter... Qual o passo a passo, desde a execução do programa, até obter o erro ??

Daniel,

Passo a passo é o seguinte, entrei no demo, coloquei a porta de rede \\127.0.0.1\tp650, como eu disse é local mas poderia ser \\192.168.0.30\tp650 (que é como outra máquina da minha rede vê a minha) e daí ativei, desativei, ativei novamente e aqui já dá o erro. Lembrando, que pelo USB:Tanca local ou se tivesse RAW:Tanca-TP650 posso fazer o procedimento que o erro não acontece. Também não acontece com a impressora RAW:NPI0DE3D que é uma HP via cabo de rede.

Até mais,

[aocampioni]

Daniel, 

Confirmando apenas :

- fiz o teste com o fonte que você me passou e continuou o problema. 

- fiz o teste com o fonte que você me passou, com instalação limpa do delphi e do acbr, o problema continuou, até ao abrir os projetos pela primeira vez dava o bendito erro io 103 e não só nas impressões com o writeln e o posprinter.

- removi novamente todo acbr e instalei a versão anterior que eu tinha (sempre guardo) de 06/01/2020 e funcionou, sem problemas, tive que remover todos os ACBrDeviceSerial dos fontes onde tinha a unit ACBrDevice pois não está presente esse arquivo nessa versão.

Então, verde funcionando, vermelho é só instalar que passo a ter erro io 103 até na hora de abrir o projeto, não só na impressão com o prosprinter ou usando o writeln.

O que pode ser feito? Há mais algum teste que quer que eu faça?

Até mais,

[Waldir Paim]

Nesse link: http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.EInOutError

Tem umas dicas que podem nos ajudar a resolver esse problema.
 

Citar

103

File not open

Reported by CloseFile, Read Write, Seek, Eof, FilePos, FileSize, Flush, BlockRead, or BlockWrite if the file is not open.

Me parece que em algum ponto o arquivo foi fechado e em seguida ele passa a apresentar esse erro nas chamadas seguintes.

Eu resolvi aqui aplicando temporariamente em todas as chamadas as diretivas {$I-} e {$I+}

Precisa ser aplicado  também na unit ACBrECFNaoFiscal.pas

Pode ser a falta de fazer a correção nessa unit o motivo da persistência de seus erros.

[aocampioni]

Então Waldir, muito estranho, eu fiz aplicação desse item que você mencionou em todas minhas chamadas, inclusive não só impressão, mas também quando eu precisei ler ou gravar arquivos textos em algumas rotinas. Fiz em todas mas não resolveu. Apenas gostaria de dizer, que aparentemente depois que o ACBrDeviceSerial entrou na jogada (pois eu não tinha ele quando atualizei em 06/01/2020) o erro começou a aparecer. Pode ser alguma coincidência. pode estar em alguma rotina nova, ou alguma outra alterada/melhorada, não sei. Fiz o teste na outra máquina que estava funcionando também, atualizei o ACBR lá com as últimas revisões até o dia 10/02 e o erro começou a acontecer também. Voltei essa versão que baixei em 06/01 e o erro não aconteceu mais.

Fiquei preocupado pois agora não posso ter as últimas alterações no ACBr enquanto não descobrir o que pode estar ocorrendo de fato, mas sigo testando, com a versão / correções até 06/01 não estou tendo problemas.

Até mais,

[Waldir Paim]

Foi feito um grande re-factore nessas units recentemente e esse é um efeito colateral minimo se levar em consideração a imensa alteração que esses fontes vem sofrendo nesses últimos dias.

Fique tranquilo!

O problema se resolvido! use a sua versão que funciona!

Assim que estiver bem testado você volta a usar a versão atualizada.

[aocampioni]

Waldir,

Sinceramente digo que me preocupo mas sei o que tem por traz de todo esse projeto. Essa sim é uma grande equipe de desenvolvimento, das melhores que já vi. Do outro lado, muitos usuários testando e é isso que fazcom que o ACBr seja esse sucesso que é hoje. Sei que será resolvido e o que nós usuários pudermos fazer para contribuir, faremos.

Estou agora copiando essa versão de 06/01 para um diretório isolado e vou fazer um SVN Update nele lá e voltar algumas revisões pra chegar em 06/01 e de lá pra cá tentar identificar algo. Qualquer coisa posto aqui.

Muito obrigado, abraço e bom dia.

 

[Daniel Simoes]

O ACBrDevice, usa várias classes, para imprimir nos diferentes tipos de porta...  Não adianta comparar Impressão USB, RAW e rede... são completamente diferentes, e tratados por fontes completamente diferentes...

Se voltar revisões, as novas Units, com as Classes não existirão...

A Unit que eu anexei já estava toda "cercada" por diretivas {$I-} {$i+}  (basta comparar os fontes usando o WinMerge)

[Waldir Paim]

2 minutos atrás, Daniel Simoes disse:

O ACBrDevice, usa várias classes, para imprimir nos diferentes tipos de porta...  Não adianta comparar Impressão USB, RAW e rede... são completamente diferentes, e tratados por fontes completamente diferentes...

Se voltar revisões, as novas Units, com as Classes não existirão...

A Unit que eu anexei já estava toda "cercada" por diretivas {$I-} {$i+}  (basta comparar os fontes usando o WinMerge)

Aplica pra gente também na unit ACBrECFNaoFiscal.pas que pra mim é ela a causadora do erro!

Assim que sobrar um tempo vou dar uma analisada no fluxo e ver se consigo entender onde o arquivo é fechado.

[aocampioni]

Waldir e Daniel,

Bom dia. Olha, olhando aqui com um pouco mais de calma (não consegui acompanhar todo fluxo pois me falta tempo e certa competência) mas notei que falta aplicar as diretivas também no arquivo ACBrDeviceRaw. No arquivo ACBrECFNaoFiscal não notei que precisa dessas diretivas se bem que há pontos em que elas 'calham'. A impressão, como o Waldir disse mesmo, é que após um assign pra começar a trabalhar com Reset ou Rewrite em algum ponto arquivo parace ser fechado antes de eu comandar Reset ou Rewrite, mas após acontecer pela primeira vez ele parece permanecer aberto (ou é ao contrário tá, como eu disse não tive tempo, nem competência, pra acompanhar o fluxo) pois se eu voltar pra executar novamente a rotina do sistema e não dá o erro.

E aí ao final do processo tudo ocorre corretamente, mas, se eu for imprimir novamente dá o mesmo erro 103 e aí, denovo, se eu repetir em seguida ocorre normalmente. 

Então vamos lá, executo o processo;

        // primeira vez
        Assignfile(iImp,sPorta); 
        {$I-}
        Rewrite(iImp); { aqui surge o erro 1ª vez }
        IOResult;
        {$I+}
        Writeln(iImp,sConfigInicial);  
                                             
                       
        // segunda vez
        Assignfile(iImp,sPorta); 
        {$I-}
        Rewrite(iImp); { não acontece o erro mais }
        IOResult;
        {$I+}
        Writeln(iImp,sConfigInicial);  
                                             
        // terceira vez
        Assignfile(iImp,sPorta); 
        {$I-}
        Rewrite(iImp);   { acontece erro novamente }
        IOResult;
        {$I+}
        Writeln(iImp,sConfigInicial); 

Claro que se eu fizer essa super ultra gambi, tudo funciona. 

        try
            Assignfile(iImp,sPorta);
            try
              {$I-}
              Rewrite(iImp);
              IOResult;
              {$I+}
            except
            end;
        finally
            {$I-}
            Rewrite(iImp);
            IOResult;
            {$I+}
        end;

Mas são muitos pontos e muitas situações dentro do meu software. Como na volta das revisões não peguei nada que me atrapalhasse resolvi voltar pra versão onde o ACBrDevice é único.

Tá aí, foi o que consegui reproduzir. Se ajudar tá valendo.

Obrigado por enquanto pessoal.

 

Editado 13 Fevereiro, 2020 por aocampioni

[Waldir Paim]

Citar

        // primeira vez
        Assignfile(iImp,sPorta); 
        {$I-}
        Rewrite(iImp); { aqui surge o erro 1ª vez }
        IOResult;
        {$I+}
        Writeln(iImp,sConfigInicial);  
                                          

Nesse seu código acima  eu usaria assim:
 

Citar

        // primeira vez
{$I-} 
        Assignfile(iImp,sPorta); 
        Rewrite(iImp); { aqui surge o erro 1ª vez }
        Writeln(iImp,sConfigInicial);
        IOResult;  
{$I+}

 

 

[aocampioni]

Opa, vou verificar Waldir e aplicar esse workaround aqui no meu código, valeu.

Abraço.

[Daniel Simoes]

23 horas atrás, Waldir Paim disse:

Aplica pra gente também na unit ACBrECFNaoFiscal.pas que pra mim é ela a causadora do erro!

Assim que sobrar um tempo vou dar uma analisada no fluxo e ver se consigo entender onde o arquivo é fechado.

@Waldir Paim, você tem alguma sugestão de onde as checagens de Erro de I/O devem ser desabilitadas ?

Usar ela em excesso, pode ocultar erros que deveriam ser informados, como Path inválido, falta de permissão, etc

https://www.freepascal.org/docs-html/rtl/system/ioresult.html

[Waldir Paim]

5 minutos atrás, Daniel Simoes disse:

@Waldir Paim, você tem alguma sugestão de onde as checagens de Erro de I/O devem ser desabilitadas ?

Usar ela em excesso, pode ocultar erros que deveriam ser informados, como Path inválido, falta de permissão, etc

https://www.freepascal.org/docs-html/rtl/system/ioresult.html

Vou arrumar um tempo amanha e concluir os testes. e anexo aqui as units alteradas.

[Daniel Simoes]

Apliquei um possível ajuste, nos fontes do SVN... Commit [r19109]
 

Citar

 

-- ACBrDeviceBlueTooth --
[*] Ajuste para permitir a porta como "BTH", para conectar no primeiro dispositivo
    Pareado, disponível na lista

-- ACBrDeviceLPT --
[-] Ajuste para evitar a Erro I/O Error 103, quando ativando a Porta
    http://www.projetoacbr.com.br/forum/index.php?showtopic=56274
[-] Correção de .A.V quando Fechando a Porta e "UsarStream = True"
    (por: DSA)      

 

 

Aparentemente, a única coisa que estava faltando, era chamar IOResult, após fechar o arquivo, pois esse método Zera o último Erro de I/O

 

[aocampioni]

17 horas atrás, Daniel Simoes disse:

Apliquei um possível ajuste, nos fontes do SVN... Commit [r19109]
 

 

Aparentemente, a única coisa que estava faltando, era chamar IOResult, após fechar o arquivo, pois esse método Zera o último Erro de I/O

 

ok Daniel, farei mais uns testes esse fim de semana e na segundona reporto como está tá ok. Obrigado pessoal.

Abraço.

[aocampioni]

Pessoal,

Boa tarde. Dando um retorno prometido sobre a situação é o seguinte. Em 90% do tempo não consigo usar mais os comandos a :

        Assignfile(iImp,'\\192.168.100.97\tp650'); 
        Rewrite(iImp); <==  agora o erro é i/o error 1265
        Writeln(iImp,sCodigoInicializacaoImp); <== não chega aqui.

Se eu coloco

        Assignfile(iImp,'\\192.168.100.97\tp650'); 
        {$I-}
        Rewrite(iImp); <==  engole o erro
        {$I+}
        Writeln(iImp,sCodigoInicializacaoImp); <== então dá i/o error 103

No posprinter, tudo resolvido, digo, no programa de exemplo. Ativação, impressão. Os arquivos texto que abro e leio utilizando o AssignFile também estão ok, mesmo estando em qualquer local, mesmo compartilhado.  Analisando o antigo arquivo ACBrDevice e agora os novos ACBrDevice e ACBrDeviceSerial, a impressão que tenho é que muitos recursos são utilizados porque muitas classes são criadas de uma vez. (LPT, SERIAL, TXT, RAW). No meu datamodule que instancio quando crio de cara tem um ACBrECF pra caso a aplicação utilizar ECF já verificar o estado da impressora (se está em erro ou ainda em venda, caso caia a energia , já corrige o estado de erro). Quando entro na tela de vendas, tenho componentes de balança, leitor, gaveta, display, ou seja, muitas vezes se passa pelo device e instancia-se todas essas classes. Acho que o erro 1265 (que por acaso não encontrei gogleando) mais se parece com um MANY RESOURCES OPENED. Veja , não tenho competência pra isso tá, só minha impressão. No antigo ACBrDevice era apenas separado por tipos (fsDeviceType: dtTCP, dtSerial, dtFile, dtParallel dtUSB, dtRawPrinter) e a instância era 1 apenas e na hora de ver quem é quem perguntava-se pelo tipo mas depois cada tipo virou uma classe a ser instanciada.

Mais alguma dica/sugestão do que ser feito ?

 

Editado 18 Fevereiro, 2020 por aocampioni

[Daniel Simoes]

Não tem relação como o ACBr...

https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-

 

Citar

 

1265 (0x4F1)

The system cannot contact a domain controller to service the authentication request. Please try again later.

 

Problema na Rede

4 minutos atrás, aocampioni disse:

No antigo ACBrDevice era apenas separado por tipos (fsDeviceType: dtTCP, dtSerial, dtFile, dtParallel dtUSB, dtRawPrinter) e a instância era 1 apenas e na hora de ver quem é quem perguntava-se pelo tipo mas depois cada tipo virou uma classe a ser instanciada

Os fontes foram apenas separados... na versão antiga, todos estavam declarados na mesma Unit...

[aocampioni]

Daniel, obrigado. Matou a pau, erro em uma máquina que tenho aqui que simula o mesmo ambiente que tem na maioria dos clientes. Windows 7. Um KB estava desatualizado nela (assim como em muitos dos clientes) e por isso não rodou a impressão. Rodei pela minha que tem windows 10 (no começo do post eu havia rodado na minha e deu erro 103) e não deu mais nenhum erro. Engraçado que pelo posprinter , lá na máquina que tem windows 7 funcionou.

Mas é isso, acredito que está resolvido essa questão no ACBr. 

Obrigado mais uma vez e até mais.

Editado 18 Fevereiro, 2020 por aocampioni

[Juliana Tamizou]

Obrigado por reportar.

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