PC Toledo

Se o colega está com dificuldades de capturar via TSR, será que em background não venha acontecer o mesmo ?. Você mesmo indicou substtuir isso por uma função própria. A questão do usuário vir a precisar digitar manualmente o código, bastaria incrementar nesse loopin da função, uma instrução que pressionado F10 (por exemplo) abra um outro GET (GET dentro de outro GET, eu acostumo usar o GETINPUT da CT.LIB) e daí endiate continuar com o looping. Claro que para esta outra situação limparia o buffer após digitação manual (por precaução).

Se o colega está com dificuldades de capturar via TSR

Acho que a dificuldade mesmo está em usar aquele programa que recebeu. A tarefa em si é das mais simples.

uma instrução que pressionado F10 (por exemplo) abra um outro GET

É quase certeza que o cliente ia chiar por isso. O ideal, a meu ver, é que o leitor serial tenha comportamento semelhante ao de teclado. Dá pra simular. É só ter o bendito código rodando em background em problema.

Maligno escreveu:

uma instrução que pressionado F10 (por exemplo) abra um outro GET

É quase certeza que o cliente ia chiar por isso.

Claro que não, estou falando CASO precise, não tem aquela questão que a etiquetas está enrugada e não dá para o leitor ler ?. Falo tão somente apenas para uma POSSÍVEL intervenção do usuário.

Maligno escreveu:O ideal, a meu ver, é que o leitor serial tenha comportamento semelhante ao de teclado.

Sim, era por isso que eu cheguei a sugerir ao Rubens para trocar o leitor por outro com entra/saída para teclado, aí a coisa estava simplificadíssima.

Maligno escreveu:É só ter o bendito código rodando em background em problema.

Ou fazer a função que leia a todo segundo (digamos) toda vez que se possicionar no GET em que tem que ser dados a digitação do produto. Pois o que eu tinha proposto desde o início era pôr um WHEN naquele GET a fim de chamar a função que capture toda entrada pela serial. Por quê achas que essa função em looping não iria funcionar ?

Por quê achas que essa função em looping não iria funcionar ?

Porque as cláusulas do GET só funcionam como gatilho de evento. Não dá pra sair do GET, ler a serial e voltar. Pra tornar isso realidade seria necessário alterar o GETSYS. Seria relativamente simples, mas talvez o molho saísse mais caro que o peixe.

Sim concordo no que você disse. Mas eu NÃO estou propondo isso.
Veja tenho um GET e nele tenho um WHEN (que só sai quando eu quiser) que chama a função de captura_serial. É nessa função que ocorre a leitura da serial e que após validada (dentro do looping mesmo) irá sair dessa função retornando .T. mas antes executo o KEYBOARD <string_capturada> que prencherá o GET conforme picture (se quiser) e final enter para retornar ao GET a fim de que dê sequência a entrada de mais produtos, certo ?

Com isto dá para imaginar que existem ao menos dois LOOPINGs, um que atenderá a inclusão de itens e mostrar em tela (assim como alguém solcitou exemplo e o Toledo deu exemplo) e outro looping é para ler e capturar a saída serial cada segundo.

Supondo que nada venha pela serial, ele ficará esperando até que algum valor entre. Se o operador quiser digitar algo terá de pressionar uma tecla de escape qualquer para entrar no GET. Isso? Se for, é isso que eu disse que gera certo incômodo. Mas dá certo assim também.

Maligno escreveu:Supondo que nada venha pela serial, ele ficará esperando até que algum valor entre.

Isso mesmo.

Maligno escreveu:Se o operador quiser digitar algo terá de pressionar uma tecla de escape qualquer para entrar no GET. Isso?

Entrar em outro tipo de GET, eu indiquei o uso do GETINPUT da CT.LIB que não influi em absolutamente nada no GET vigente. Seria atribuir a uma variável o conteúdo dessa função GETINPUT (que buferiza as telcas do teclado quando pressionadas).

Maligno escreveu:Se for, é isso que eu disse que gera certo incômodo.

Não, pelo uso do GETINPUT() da CT.LIB

Eu tenho certeza do que estou falando, ora porque passei por situações mais complexa que essa no referente a captura de serial. Você imaginou captura tecla a tecla de um teclado serial (PINPAD, aquele que utilizam os bancos para digitar senhas, por exemplo) e exibir em tela com um caracter (tipo "*", ou CHR(254)) ? Evidentemente esconde a senha mas aparece que o usuário atrás do balcão está digitando a sua senha, conforme vai digitando. Isso eu considero mais complexo que o que o colega está necessitando.

Não, pelo uso do GETINPUT() da CT.LIB

Se assim você diz, acredito. Pensei que fosse o GET tradicional. Pois essa aí nem conheço. Uso a CATools minimamente.

É uma função muito boa, só que para fazer navegação através de vários GETINPUT, tem que ser feito um tratamento na unha para que possar passar de um GET a outro digamos. Mas resolve bonitinho, caso contrário daria para fazer uma função da mesma utilidade, aliás eu ja tenho isso, mas para não complicar mais ainda a vida dos colegas é melhor fazer pelo GETINPUT ja que trata-se de apenas um GET (inventado, vamos dizer).

Mas que acha, Maligno´? É viável o que estou dizendo, acha ainda que utilizar software em background seria o ideal ? E o problema seria achar um compatível com XP. Qúê estranho a Sweda vir a fazer um aplicativo tão pesado e não tão compatível... é estranho.

Ainda acho que o ideal seria ter um leitor serial que se comportasse como se fosse um leitor por teclado. Aliás, a coisa é feita pra funcionar assim. Só que, por uma infelicidade, o colega teve problema com o programa de conversão. Mas se ele não se acertar com isso, fica mais esta opção.

Espero que o colega Rubens não tenha desistido com a minha falação. Eu acho que esse leitor serial é chatinho que o scaner sendo para saída/teclado iria facilitar em tudo. Mas há vezes que o complicado que é gostoso, e se dá mais valor quando se conseguem superar os desafios. Rubens, agora depende de você. Faça um teste para saber o que você consegue capturar quando passa algum produto no scaner. Para saber se contém CHR(13) ou tem tamanho fixo, para poder localizar se o código capturado está cadastrado e para sair do looping e atribuir a váriável de aquele GET que está esperando faz horas... hihihi

Pensei que fosse o GET tradicional

Maligno, eu nem uso GET com o leitor... Botei um inkey(0) dentro de um loop, vou guardando as entradas (feitas via teclado ou leitor) numa variável, aí quando chega no tamanho 13 ou pinta um ENTER, saio do loop e toco em frente...

Perfeito, acho que também é válido, mas como mínimo seria dois loopings que teriamos que aplicar no caso do Ruben ? Não sei se você concorda.

Gente tô passado.. bobo mesmo.. hehehe
Aconteceu tanta coisa neste tópico depois que passei por aqui.. pela última... vez.. a última vez que recebi mensagem indicando que alguem tinha respondido foi quando o maligno sugeriu baixar outros programas para o scanner.. e falei que achava a melhor solucao...

Vamos a alguns esclarecimentos:

1º - O programa disponibilizado pela Sweda, funciona beleza, e tive problemas com o windows xp.
2º - Tentei uma rotina usando a CATOOLS, mas pela inexperiência com o negócio não consegui colocar para funcionar... volto a repetir o scanner serial tem que ler o codigo automaticamente, num PDV não tem como voce colocar para pressionar uma tecla toda vez que passa um produto... fica dificil de trabalhar... o operador passa o produto em um get e o programa tem que fazer o tratamento do restante, salvo nos casos em que o cliente traz um produto de peso que nao passou pela balanca nem gerou um código de barras aí sim.. dá se um enter no código e pula para a qtde, lê o peso ou a qtde e volta para ler o código... pelo menos é assim que funciona comigo... Entao como a função vai ficar monitorando ao get do codigo onde vai ler o scanner com a cláusula WHEN, enquanto nao passar um codigo nao vai sair dali... certo..!!! só sai quando ler algo.. usei a opção de ler 13vezes o buffer e nao funcionou... não sei porque, chegou a ler mas lia o codigo incompleto.. bem nao me aprofundei muito, incluse com a opção sugerida i pelo Pablo... o tal do GETINPUT, nao tinha sido mencionado ainda... desisti dessa opção de criar a função...
3º A Função da Sweda não eleva o processamento, e sim a função lendo a serial porque ela entra em loop infinito...

Bem depois de muitos testes e trazer o scanner do cliente para o meu escritorio, consegui trabalhar um pouco em paz, e descobri o seguinte: Quando carrego a linha do TSR no prompt do DOS, serial com4:9600,n,8,1 CR, o leitor funcionava perfeitamente.. na linha do prompt, entao resolvi fazer testes no programa e funcionou... Quando colocava para carregar o TSR dentro de um bat e carregava o programa logo em seguida, nao funcionava... não sei porque...
Entao para resolver o problema fiz o seguinte... ensinei para os operadores: Entrar no prompt do DOS, carregar o TSR do Scanner e carregar um bat que gera umas variáveis de identificação do pdv e carrega o programa...
Assim funciona... Bem pelo menos de ontem para cá está funcionando e não deu pau ainda.. estou ligando de duas em duas horas para ver o andamento.. ainda nao deu problema... Mas é esquisito né.. imagina o operador digitando no prompt do DOS toda vez que vai entrar no programa aquele monte de código... Mas funcionou e tá limpando minha barra com o cliente...

Bem pessoal agora tenho que tomar uma decisão muito dificil que é rever os conceitos da programação e decidir que rumo tomar... Infelizmente constatei que os fabricantes simplesmente abandonaram o nosso bom e velho clipper... !!!

Em tempo, eu gostaria de disponibilizar esse programa de PDV junto com os fontes, porque tenho percebido que muitos usuários do Fórum precisam de uma ferramenta assim e não sabem pode onde começar... e este programa ainda precisa de melhorias e se tiver mais gente usando quem sabe ajudam a melhorar esse sistema... de repente até sai a rotina de ler o scanner, né.. heheh

Por enquanto valeu. gente.. obrigado pela ajuda...

O importante é que o caso está resolvido. Pelo menos agora a sua barra ficou limpa com o cliente. Quanto aos fontes, você poderia colocá-los na seção de fontes e deixar os colegas se manifestarem a respeito.
Mas, continue pensando na possibilidade de trocar o programa da Sweda por algum outro em linha de comando mesmo. Procurei na Internet mas não consegui achar nada, mesmo que fossem apenas fontes. Aliás, se puder, poderia tentar uma coisa: colocar esse fonte no autoexec.nt do XP. Assim, quando a sessão for aberta, o programa já entra funcionando. Daí é só executar o BAT do programa.