Harbour - Keyboard/HB_KeyPut registram codigo barras errado!

ANDRIL · Mensagem por **ANDRIL** » 29 Jan 2016 13:52

Pessoal, tenho uma rotina em um DbEdit() que ao teclar um número abre uma busca por código, ou código de barras.
Converti meu sistema para Harbour 3.2 e notei que ao passar o código de barras vem faltando um número.
Exemplo:

codigo: 7896185310576
sai apenas: 796185310576 comeu o 8 segundo caracter

Não é problema do leitor, pois testei vários para ter certeza que se tratava do código. O problema é que o Harbour não esta tratando o Keyboard como o Clipper tratava e mesmo substituindo por HB_KeyPut() não consigo obter o resultado correto.

Postei meu código de testes, já que no sistema é muito grande, isolei para ter certeza que não era nada vinculado ao código do sistema.

Código: Selecionar todos

#include "inkey.ch" 
set scor off
set talk off
set typeahead to 4000
priv ar1:={{"campo","@!","campo"}}

dbcreate("cliente.dbf",{{"CAMPO","C",60,0}})

cls
c_p=space(20)
use cliente


dbedit(00,00,22,79,"","minhafuncao")

//BRW_ARQ(00,00,22,79,ar1)

close all
return


function minhafuncao
parameters modo, campo


if (LastKey() >= 48 .AND. LastKey() <= 57)
         
         
         //--USO EM HARBOUR 3.2 descomente a linha abaixo
         //  ja usei HB_KeyPut( CHR( lastkey() )) e nao deu certo, o que mais
         //  se aproxima é esta função, porem nao da certo tambem.
         //  exemplo: 7896185310576 
         //  sai apenas 796185310576 o primeiro caracter nunca vem junto
         //SETLASTKEY( CHR(LastKey()) )
         *HB_KeyPut( CHR(LastKey()) )
         
         //--USO EM CLIPPER 5.2 descomente a linha abaixo
         //  Funciona perfeitamente, ja no harbour 3.2 nao, exemplo: 7896185310576 
         //  sai apenas 7185310576 come o 896
                
         *KEYBOARD CHR(lastkey() )
        


	  @24,00 say "Codigo:"
	  setcursor(3)
	  @24,10 get c_p //pict"99999999999999"
	  read
	  setcursor(0)
	  
	  return 1
	  
elseif Lastkey()=27
      return 0
else
inkey(0.1)
return 1
endif

Se compilar no Clipper funciona corretamente. Já procurei no fórum e seguindo dicas, usei a função SetLastKey(), porem também não deu certo.
Será que é bug do HARBOUR?

Acho que em TBrowse deva até conseguir, porém esta rotina envolve praticamente 50% do sistema, se tiver que alterá-la vai ser duro, por isso procuro alguma solução já aproveitando o código existente.

Até+

Mensagem por **alxsts** » 29 Jan 2016 14:43

Olá!

HB_KEYPUT() recebe como parâmetro um valor númerico, representando o código Inkey() da tecla a inserir no buffer do teclado. Assim, não é necessário converter o valor para o caracter que ele representa, com a função CHR(). Tente:

Código: Selecionar todos

HB_KeyPut( LastKey() )

ANDRIL · Mensagem por **ANDRIL** » 29 Jan 2016 15:22

alxsts, já havia tentando esta combinação e não deu certo, também tentei HB_KeyPut( Inkey() ), HB_KeyPut( Inkey(0.5) ) e não funcionou.
Incrível!!! Aceito sugestões.

Mensagem por **fladimir** » 29 Jan 2016 20:50

Tentou compilar um outro dbedit.prg junto com teu projeto pra ver se resolve?

Lembro q em 2009 qdo migrei pra harbour tive um problema semelhante e não lembro como resolvi, o fato é q hj uso o harbour 3.2 e não tenho esse problema...

Vou testar teu exemplo e te falo.

[]´s

Mensagem por **fladimir** » 29 Jan 2016 20:57

faça um teste ai... muda a linha 26 para a debaixo e veja se funciona pra eliminarmos questões relacionadas ao Harbour.

Código: Selecionar todos

	if LastKey()  != 27

ANDRIL · Mensagem por **ANDRIL** » 31 Jan 2016 11:43

fladimir escreveu:muda a linha 26 para a debaixo e veja se funciona pra eliminarmos questões relacionadas ao Harbour

Não deu certo também.

Não teve jeito mudei de DbEdit() para TBrowse() a rotina em questão e o problema foi resolvido depois de muito trabalho. A questão esta no comportamento de Lastkey() e Inkey() quando usando em Harbour, dentro da função de controle do DbEdit. No TBrowse, também ocorre o mesmo problema ao tentar identificar a tecla acionada usando Lastkey(), porem, neste eu posso substituir para o Inkey() já no Dbedit o Inkey() tem um efeito diferente, não me pergunte o por que. Tenho notado alguns comportamento em algumas funções do Harbour que diferem na execução em relação ao Clipper, por exemplo, aSize dentro do Achoice, DbEdit que causam um transtorno danado na conversão do sistema.

Obrigado à todos.
Ate+

Mensagem por **fladimir** » 31 Jan 2016 12:41

Aki deu certo sem mudar nada além da linha citada, ou seja, da forma q vc postou dava problema, ai troquei a linha 26 e recompilei o projeto e testei novamente e deu certo.

ANDRIL · Mensagem por **ANDRIL** » 31 Jan 2016 13:20

Quando troquei a linha a única mudança foi não poder sair do DbEdit com o ESC. Testou usando uma aparelho Leitor de Código de Barras? Quando se digita na mão não ocorria o problema. Estou usando a versão Harbour 3.2.0dev (r1502201040) e a sua qual é?
Ate+

Mensagem por **fladimir** » 31 Jan 2016 14:17

não testei com leitor, simulei um leitor copiando o código de barras na memória depois na janela do prompt fiz um ALT ESPACO editar colar, mas vou testar amanhã com 1 leitor e te falo.

minha versão é:

3.2.0dev (r1503211154) + Mingw

Mensagem por **asimoes** » 31 Jan 2016 21:44

Um teste compilado com harbour 3.4

Código: Selecionar todos

cVar1:=Space(13)
cVar2:=Space(13)
Keyboard "7896185310576" //simula entrada de teclado
nKey:=Inkey()
IF (nKey >= 48 .AND. nKey <= 57
   @ 10, 00 Get cVar1
   @ 11, 00 Get cVar2
   READ
ENDIF

Este teste resulta:

: Resultado; Screen Shot 01-31-16 at 09.36 PM.PNG (4.54 KiB) Exibido 2359 vezes

Mensagem por **asimoes** » 31 Jan 2016 21:51

Assim funciona:

Código: Selecionar todos

Keyboard      "7896185310576"
HB_KeyPut( LastKey() )
if (LastKey() >= 48 .OR. LastKey() <= 57)
     @ 10, 00 GET cTecla PICTURE "@ 9999999999999"
     @ 11, 00 GET cGet
     READ
 endif

Mensagem por **alxsts** » 31 Jan 2016 23:17

Olá!

@Simões:

no código que você postou acima, a função Inkey() retira o primeiro carácter do buffer de leitura. Acho que este é o motivo pelo qual ele some, conforme mostra a imagem postada. Tente assim:

Código: Selecionar todos

LOCAL cVar1:=Space(13)
LOCAL cVar2:=Space(13)

LOCAL cVar3 := "7896185310576"

Keyboard cVar3 //simula entrada de teclado

nKey:=Inkey()

IF (nKey >= 48 .AND. nKey <= 57

 Keyboard cVar3 //simula entrada de teclado

 @ 10, 00 Get cVar1
 @ 11, 00 Get cVar2
 READ
ENDIF

Acho tudo isto uma loucura... se realmente estiver acontecendo (não testei) talve seja melhor reportar o bug à equipe dos Harbours.

Mensagem por **JoséQuintas** » 01 Fev 2016 00:21

Vocês estão confundindo tudo.

KEYBOARD limpa o buffer de teclado e coloca os caracteres lá

Key_put() apenas acrescenta ao buffer que já existe

Inkey() retira uma letra do teclado

Código: Selecionar todos

KEYBOARD "sfsfsddsfdfdsds"
@ 1, 0 GET xCodigo PICTURE "@!"
READ

Isso tem que funcionar.

No tbrowse/dbEdit é outra história.
Sempre pode existir alguma rotina de agilização que acaba eliminando letras, com algum Inkey().
É revisar.

Nota:
Se é getsys personalizada, também tem que revisar.

Mensagem por **JoséQuintas** » 01 Fev 2016 00:26

Um jeito simples de conferir é acompanhar pelo debug.

Mensagem por **JoséQuintas** » 01 Fev 2016 00:38

Isto é porque come a primeira letra?

Código: Selecionar todos

KEYBOARD CHR(lastkey() ) 
           
   
      @24,00 say "Codigo:" 
      setcursor(3) 
      @24,10 get c_p //pict"99999999999999"

Pra resolver a primeira letra, comeu as outras kkkkk

Tente isto:

Código: Selecionar todos

nCode := LastKey()
@ 24, 10 GET c_p
READ
c_p := Chr( nCode ) + c_p