Página 2 de 4

Enviado: 31 Jul 2007 13:31
por rubens
Gente é o seguinte... o leitor em windows 98 funciona blz... inclusive dá um enter no final da leitura... independente do jeito que você passe o código de barras... então estive pensando que se a rotina funcionar o meu medo de enviar para o get já tá resolvido... o problema é que está tudo instalado no pdv... como já estou ficando queimado com o cliente não tenho coragem de pedir para trazer o scanner para o meu computador e trabalhar mais sossegado.. entao venho faço um alteração, vou lá não funciona... imagino que saibam o que é isso.. hehe

Quanto ao programa maligno a Sweda me mandou uma versão mais nova feita agora no mes 02/2007.. infelizmente nao funcionou.. estou procurando alguma para levar.. vou voltar lá agora a tarde... mas precisava ir meio armado... né, para não ficar queimando cartucho...
Se funcionar posto aqui se não funcionar posto também... mas hoje já estou de ultimato se nao funcionar.. bau... bau.... inclusive tou levando outra maquina junto ... vamos ver..

Enviado: 31 Jul 2007 13:45
por Maligno
acho que aquele leitor de supermercado, trabalho com vários tipos
Imagino que seja aquele leitor omnidirecional fixo, a laser. Não conheço na intimidade :), mas creio que deve ser como o meu de mão, que lê quase todos os tipos de códigos.

Enviado: 31 Jul 2007 14:06
por Maligno
já estou ficando queimado com o cliente
Normalmente o cliente não liga muito para as dificuldades. Ele só quer saber das soluções. Sob certo ponto de vista, ele não está tão errado. Mas ele deveria ser mais compreensivo.
Quanto ao programa maligno a Sweda me mandou uma versão mais nova feita agora no mes 02/2007
Você se confundiu. É um programa (disponível para download) feito em 30/042007. Baixei e parece que funciona no XP normalmente. Logicamente não tive como testar. Mas percebi que é um programa não muito bem dimensionado. Como é um TSR, ele fica constantemente lendo a serial. Só que acaba tornando toda a sessão DOS mais lenta. Se tivesse o fonte dele, seria fácil recompilar.

Acho que a solução é conseguir outro programa. Melhor do que fazer essa leitura você mesmo, pelo seu programa. Veja os link abaixo:

http://www.softforall.com/Utilities/Sys ... 140085.htm
http://www.batchconverter.com/sWedge-do ... 0930.shtml
http://www.freedownloadmanager.org/down ... d_21923_p/

Vi apenas esses, mas há outros no Google. É só procurar, baixar e analisar qual o que melhor se encaixa no problema. Acredito que qualquer um deles funcionará a contento.

Enviado: 31 Jul 2007 14:14
por Maligno
Troque o primeiro link por http://www.keyinjector.com
O download por aquele link está dando erro 404. Mas esse agora está ok.

Enviado: 31 Jul 2007 14:20
por Maligno
São várias opções de conversores. Vai aí mais um: http://www.downloadry.com/freeware/bill ... d-3189.htm
Acho que todos os que passei são GUI. Vou ver se encontro um que seja simples, pequeno e para linha de comando, com fontes.

Enviado: 31 Jul 2007 15:13
por Eolo
Maligno,

Tenho um leitor COMTAC (via teclado), vou lhe mandar o manual dele (PDF) pro seu email, quem sabe ajuda.

Estive dando uma olhada rápida e, pelo que entendi, parece que por ex o chr(13) no final não está no EAN e é de fato gerado PELO LEITOR no final da leitura. Além desta, tem uma série de outras configurações que se pode fazer...

Complementando: quem sabe não é alguma config que tá faltando ou indevida no caso do Rubens?

Enviado: 31 Jul 2007 15:17
por Pablo César
O leitor é serial não por teclado. Essa é a grande diferença EOLO.

Eu recomendo usar a IOLIB que achei melhor que usar a CT.LIB para ler a bufferização pela serial. Mas fazendo testes no local, realmente fica muito desgastante. Procure Rubens que o cliente possa emprestar o aparelho ou até disponibilizar um terminal para você. O cliente deve entender que esta não é uma situação comum, que uma vez que você consiga configurar, não irá ter problemas, explique para ele.

Enviado: 31 Jul 2007 15:19
por Maligno
parece que por ex o chr(13) no final não está no EAN e é de fato gerado PELO LEITOR no final da leitura
Sem dúvida. E muitos outros caracteres podem ser inseridos ou mesmo deletados do código lido. É só configurar o scanner.
quem sabe não é alguma config que tá faltando ou indevida no caso do Rubens?
Possível é. Só sei que o programa funcionou aqui no meu XP. Mas, claro, não tenho nenhum scanner serial. Não dá pra testar. Aliás, a única coisa serial que tenho é o identificador de chamadas. Mas não dá pra usá-lo nisso.

Enviado: 31 Jul 2007 15:26
por rubens
Gente estou até agora quebrando a cabeca aqui com a rotina e pelo que percebi a sugestão do maligno é a melhor... ou seja substituir o programa residente do scanner por outro... A rotina enquanto nao se passa um codigo de barra vai ficar lendo a porta serial.. deixando o programa forçar o uso da CPU.. porque ele vai estar lendo a porta serial..
alguns minutos de teste aqui e já estava com a cpu a 100%.
Não é problema com o scanner, volto a repetir... são dois terminais, o que ainda está com o windows 98, está funcionando bala... 100%, só que o 98 dá conflito com a placa pci que acrescentar mais duas seriais para ligar a balanca e a ecf... Depois que instalei o windows xp a placa pci foi configurada corretamente e funciona beleza... inclusive do jeito que está se eu digitat o codigo manual lê e imprime na ecf e busca o peso na balanca.. A questão parece ser que o driver residente, falha no windows... em alguns casos chegou a ler o primeiro código... já no segundo já aparece mais... na instalação do programa é assim: serial com1:9600,n,8,1 CR acredito que este CR seja para dizer ao scanner para dar um enter no final da leitura... bom pelo menos é assim que funciona no windows 98... Ainda tô aguardando alguma coisa da Sweda... mas o suporte de lá é de morte...

Enviado: 31 Jul 2007 15:29
por Eolo
Que é serial e não por teclado já tava escrito antes e eu consegui entender. Esse não é o ponto.

O ponto é que, se é possível programar um leitor por teclado, também deve ser possível programar um leitor serial. E se o leitor serial tava progarmado para funfar numa porta COM com o SO X e aí se mudou para uma PCI com o SO Y, será que não cabe alterar nada na config dele [leitor]?

Enviado: 31 Jul 2007 15:32
por Maligno
alguns minutos de teste aqui e já estava com a cpu a 100%
É como eu disse: leitura mal dimensionada. Ele fica lendo demais. Daí o consumo excessivo. Se a Sweda ainda desse o fonte desse programa. Pelo tamanho e pelo conteúdo interno parece ter sido feito em ASM. Acho que seria só o caso de botar um delay nele.

Enviado: 31 Jul 2007 15:42
por Pablo César
rubens escreveu:substituir o programa residente do scanner por outro... A rotina enquanto nao se passa um codigo de barra vai ficar lendo a porta serial.. deixando o programa forçar o uso da CPU.. porque ele vai estar lendo a porta serial..
Com certeza o faria o mesmo caso consiga captura a bufferização pela serial. Volto a dizer, o importante é sabe como está vindo essa string (com chr(13) no final, sim ou não), se for então não vejo por quê usar o TSR ou até mesmo uma função sua que esteja em looping. Pois irá bastar na função verificar se esse código existe e utilizar o KEYBOARD para prencher o seu GET.

Enviado: 31 Jul 2007 15:55
por Maligno
não vejo por quê usar o TSR ou até mesmo uma função sua que esteja em looping
Mas ele precisa deste TSR pra ler a serial. Ou, claro, um código qualquer em background, mesmo que no programa dele, para ler a serial e injetar os códigos no buffer do teclado.

Enviado: 31 Jul 2007 16:06
por Pablo César
Maligno escreveu:Ou, claro, um código qualquer em background... para ler a serial
Background ? Não vejo necessidade. pode ser uma função ora feita pelo colega que fique em looping (temporizado, se quiser) para que a cada instante veja se foi acionado o leitor.
Maligno escreveu:e injetar os códigos no buffer do teclado.
Após verificado o chr(13) ou até mesmo o tamnho do código, a função é finalizada com um KEYBOARD <conteúdo_lido>

Acho que tem senso o que estou dizendo. Ja que a Sweda, não dá outro recurso. Sabemos que é possível ler a serial através da CT.LIB ou IOLIB

A questão é ver o valor a ser atribuido como temporarização, para isso seria bom verm na prática, porque um segundo é tempo suficiente, masi do que isso iria comprometer a leitura no looping.

Enviado: 31 Jul 2007 16:14
por Maligno
Background ? Não vejo necessidade. pode ser uma função ora feita pelo colega que fique em looping (temporizado, se quiser) para que a cada instante veja se foi acionado o leitor.
Mas também será possível entrar algum código via digitação. Para fazer a leitura do teclado num GET qualquer também será necessário um código em background para ler a serial. Se a leitura da serial contiver um código, este será inserido no buffer.