Inquiridor
Driver DOS para Impressoras Daruma

Discussão Geral
-
Você que possui um aplicativo DOS que comunica com impressoras fiscais e não fiscais e gostaria de usufruir do alto nível da daruma32.dll, pode usar o Observer2.
O Observer2 é escrito em c (ansi), super estável e de fácil utilização
Baixe aqui: http://www.daruma.com.br/suporte/download/observer.zip o Observer2.
O pacote inclui um aplicativo inteirinho escrito em clipper5 + fontes.
O manual de utilização do Observer pode ser baixado aqui: http://www.daruma.com.br/suporte/download/daruma32help.zip
[]'s
suporte.alexandre@daruma.com.br
Todas as Respostas
-
Realmente o Observer é bem estável, mas eu gostaria de esclarecer aqui um detalhe em relação ao compartilhamento do arquivo de retorno.
Quando gravamos o comando para a ECF utilizamos o arquivo DARUMA.CMD que será lido a cada xxx milisegundos pelo Observer. Essa definição dos xxx milisegundos é feita modificando-se a latência na tela principal do Observer, correto?
Pois bem, gravamos o comando e o Observer interpreta, conversa com a ECF e dá um retorno.
No exemplo em Clipper que foi utilizado junto com o Observer, existem 2 (dois) loops:
No primeiro:
VAR_ESPERA:=1
/*Espera que o Arquivo de Resposta Seja Criado*/
do while VAR_ESPERA > 0
if File("c:\DARUMA.RET")
VAR_ESPERA :=0
else
loop
end if
enddo
Como o comentário indica, fica esperando o arquivo ser criado. Até aí nada de mais.
No segundo:
RET_TAM:=0
/*Espera o Arquivo ter um conteudo*/
do While RET_TAM = 0
H_Handle := Fopen("c:\DARUMA.RET")
RET_TAM = FSeek( H_Handle, 0, FS_END )
Fclose(H_Handle)
enddo
H_Handle:= Fopen("c:\DARUMA.RET")
... segue o prog ...
É aqui onde pode haver um problema potencial. Como ambos progs, Observer e aplicativo estão trabalhando ao mesmo tempo no mesmo arquivo, pode dar confusão.
Porque trabalhando ao mesmo tempo? Porque no loop acima, o aplicativo espera até o arquivo DARUMA.RET possuir conteúdo. Por conteúdo entende-se de 1 byte até a leitura inteira da memória fiscal (many many bytes
porém ao identificar que o primeiro byte foi gravado no arquivo DARUMA.RET,
o aplicativo sai do loop e tenta abrir o arquivo para leitura para dar continuidade,
porém pode ocorrer um erro de acesso negado, pois o Observer AINDA está gravando os demais dados.
Se não ocorrer o acesso negado, ainda pode ser lido apenas o conteúdo parcial do arquivo pois o Observer não terminou de gravar todos os bytes.
Esclarecendo que para gravar informações em um arquivo é preciso abrir este arquivo em modo exclusivo, o que não
permitiria acesso de outros progs até o programa que abriu o arquivo fechar o mesmo.
Minha sugestão é que o Observer grave todos os bytes de retorno em um arquivo de nome qualquer e após a gravação e
o fechamento deste arquivo, efetue uma chamada para RENOMEAR o arquivo para DARUMA.RET.
Neste momento, o aplicativo vai reconhecer o DARUMA.RET e trabalhar com ele sem APÓS o Observer, evitando o
problema acima e inclusive eliminando a necessidade do 2o loop, pois só com o primeiro já poderia trabalhar bem. -
Interessante sua colocação.
Para acrescentar: eu gastei quase que 1 bobina inteira devido a problemas de retorno que eu estava obtendo. Como eu refiz minha aplicacao comercial para operar com a nova DLL, eu costumo debugar linha-a-linha minha aplicacao. Quando eu debugava, algo acontecia de nao receber os retornos. Nao me lembro agora os erros ou problemas que eu obtinha, pois na época fiquei muito stressado. Mas, enfim, eu percebi que a debugação tinha que ser feita em lugares mais apropriados, precisei comprar outra bobina! rsrsrsrrs
Enfim, nas linhas que mandam comandos para a IF, é bom nao debugar. É interessante colocar as pausas em lugares certos. Isso vale para outras marcas de IF também!
Enfim, quem programa em plataforma DOS usando o OBSERVER, vai perceber isso que estou falando.
Quanto ao recurso de aumentar ou diminuir a Latência, é muito interessante, porém preferi trabalhar no "default".
[ ]s
-
Olá Paulo,
A Latência no Observer é de quanto em quando tempo o Observer irá "bater" no HD pra pegar os arquivos de comandos criados por você, como você já explicou, e ela pode ser sim alterada através da tela principal, também conforme você colocou.
Em sua surgestão, que o Observer poderia usar um arquivo temporário para depois de completo ser renomeado, já recebemos surgestões parecidas, e foi feita uma atualização no Observer, você pode baixar a última versão dele através do link: http://desenvolvedoresdaruma.com.br/home/downloads/Observer_Executavel.exe
Com esta versão quando um comando é enviado para o Observer - criado o arquivo Daruma.cmd, automaticamente é gerado um arquivo Daruma.tmp que somente depois de completo é renomeado para Daruma.ret.
Você pode fazer um teste para conferir isso, pedindo por exemplo uma leitura X e ficar monitorando a pasta de trabalho do Observer, vai aparecer um .tmp que depois some e aparece o .ret.
Atenciosamente,
Débora Brezan Shiraiwa
Suporte ao Desenvolvedor Daruma
http://www.desenvolvedoresdaruma.com.brSkype: suporte_ddc_daruma
E-mail: suporte.ddc@daruma.com.br
Central: 0800-7703320
-
Olá Débora.
Muito obrigado pela resposta.
Posso então mudar o aplicativo para ignorar o tamanho o arquivo DARUMA.RET, apenas verificando a existência dele, pois quando ele "existir" será completo, certo?
PS: Desculpe comentar, mas ainda estou esperando o manual de programação para comunicação direta