Harbour - Keyboard/HB_KeyPut registram codigo barras errado!

[asimoes]

Se é para ler o código de barras e é uma sequencia de 13 números é só usar a PICTURE, nada além de números irá passar, não precisa nem testar com lastkey()

[asimoes]

Quintas,

Pelo debug não tem como testar, já fiz o teste aqui.

[Jairo Maia]

Olá Pessoal,

Gostaria de fazer uma observação sobre a questão desse tópico:

O problema é que o Harbour não esta tratando o Keyboard como o Clipper tratava

Andril, apesar de vários colegas terem proposto sugestões, posso garantir que o tratamento do buffer do teclado funciona EXATAMENTE igual ao Clipper.

Tenho vários sistemas de frente de caixa em varejo, e todos usam exaustivamente o leitor e nunca tive problemas em qualquer uma das versões com Harbour.

Sugiro testar seu aplicativo em outro micro. Se o problema cessar então tem algo em seu micro interferindo nesse processo de leitura do buffer. Se o problema persistir, você terá que entender o que em Harbour está interferindo em seu aplicativo, uma vez que como você disse em Clipper funciona.

NOTA: Penso que não tem nada a ver mas a única coisa que nunca usei foi Set TypeaHead To <nBuffer>.

[ANDRIL]

Pessoal não estava mais acompanhando o tópico e fiquei surpreso com todos esses comentários.

posso garantir que o tratamento do buffer do teclado funciona EXATAMENTE igual ao Clipper

Creio que seja verdade isso, porem no caso do DbEdit() acontece essa "diferença". Talvez por que no código dentro dele, haja algo com inkey() que interfira no resultado. Em outras funções funciona corretamente, até o momento.

Como postei o código, basta compilar o exemplo para Clipper e o mesmo para Harbour e verá que não funciona. Quando migramos achamos que tudo funcionará como já testamos em Clipper e deparamos com essas "pedras".

Na verdade o problema detectei no cliente, depois em outro... conforme ia atualizando, pois achava que era algum problema neles (PC, leitor etc) até que testei aqui no laboratório e detectei o problema.

A solução foi migrar para TBrowse() usando o tecl_p=INKEY(0) fez a leitura normalmente. Embora tenha causando um grande trabalho para mudar por que é a minha maior rotina, ao menos consegui fazer funcionar. Estava desesperado em não achar a solução, a maioria dos clientes usam leitor.

E olha que no meu Dbedit não tinha nenhum Inkey() e mesmo colocando-o o problema só piorava.
Ate+

[ANDRIL]

Novamente o inkey() causando problema no Harbour. Como disse passei para TBrowse e usando o inkey() consegui fazer o leitor ler corretamente. Agora estou ajustando minha função de background que fica verificando a existência de alguns arquivos, por coincidência tem um "tecl_a:=inkey(1)", já fez meu TBrowse não reconhecer corretamente os números capturados pelo leitor.

Gostaria de comparar o fonte da função inkey do Clipper e do Harbour, pena que não tenho aqui.
Até+

[asimoes]

Harbour deriva do clipper, o código em clipper provavelmente seja dificil de ver, agora em harbour você pode ver em inkey.c na pasta src\rtl

A função inkey chama hb_inkey que está em inkeyapi.c

Olhando código da dbedit

nKeyStd := hb_keyStd( Inkey(, hb_bitOr( Set( _SET_EVENTMASK ), HB_INKEY_EXT ) ) )

[asimoes]

Voltando ao assunto, tive esse problema com Hwgui objeto GET, o problema foi resolvido com SET TYPEAHEAD TO 0 (zero)

[lucimauro]

EU também tive o mesmo problema com a hwgui que não lia o código de barras da NF-e nem a pau corretamente, sempre engolia alguns números, então resolvi com o comando acima citato pelo assimoes. então acho que esse comando acima seria a solução do problema.

[Itamar M. Lins Jr.]

Ola!
Uso a Hwgui 2.20 e funciona tudo ok. Ler tudo DANFE, EAN... Copiar colocar com GET @R etc...
Talvez, na versão 1.17 ainda estava em testes UTF8, Unicode.
Tem vários FIX´s neste sentido até a 2.20.

Saudações,
Itamar M. Lins Jr.