Erro no Tbrowse

[JoséQuintas]

Aqui uso Harbour 3.4 sem nenhuma configuração especial e já fica disponível.
Só consegui gerar o erro com o fonte acima, colocando o nome errado no fonte.

Vamos considerar o básico:

O nome do método é tbrowse:SETKEY()

O erro é não existir: tbrowse:HB_SETKEY()

Se não estiver no fonte, talvez possa ser possível algum arquivo .CH estar modificando.
Pode verificar o que contém a outra linha?
Called from A040300.PRG->DBDATA(242)

O erro é chamar nome errado, que não existe, e o nome chamado é :HB_SETKEY() quando deveria ser :SETKEY()

[asimoes]

Quintas a linha 242:

oTBrowse:setKey(K_F12, {|| DiasAtraso("APA01")})

Muito estranho isso.

Está chamando outra função.

As minhas compilações são com harbour 3.4 e atualizei e gerei o harbour 2 dias atrás.

[JoséQuintas]

Vou atualizar aqui e gerar, pra ver se mudaram alguma coisa.
Um teste relativamente básico que aqui funciona:

Código: Selecionar todos

#pragma -w3
#pragma -es2
#include "inkey.ch"
request DBFCDX

PROCEDURE Main

   LOCAL oTBrowse, oKeys

   RddSetDefault( "DBFCDX" )
   dbCreate( "test", { { "CODIGO", "C", 6, 0 }, { "NOME", "C", 30, 0 } } )
   USE test
   INDEX ON field->Nome to test
   SetMode( 25, 80 )
   SET COLOR TO W/B,N/W,,,W/B
   CLS
   oTBrowse := { ;
     { "CODIGO",   { || test->Codigo } }, ;
     { "NOME",     { || Left( test->Nome, 10 ) } } }
   oKeys := { ;
      { K_ENTER, { || AlgumaCoisa() } }, ;
      { K_F2,    { || AlgumaCoisa() } } }
   FazBrowse( oTBrowse, oKeys )
   CLOSE DATABASES
   RETURN

STATIC FUNCTION AlgumaCoisa()
   RETURN NIL

FUNCTION FazBrowse( oTBrowse, oKeys )

   LOCAL oBrowse, nCont, nKey
   MEMVAR cFiltro
   PRIVATE cFiltro := ""

   oBrowse := tbrowsedb( 1, 1, MaxRow(), MaxCol() )
   oBrowse:HeadSep := Chr(196)
   oBrowse:FootSep := Chr(196)
   oBrowse:ColSep  := ""
   FOR nCont = 1 TO Len( oTBrowse )
      oBrowse:AddColumn( tbColumnNew( "|", { || "|" } ) )
      oBrowse:AddColumn( tbColumnNew( oTBrowse[ nCont, 1 ], oTBrowse[ nCont, 2 ] ) )
   NEXT
   IF .NOT. oKeys == NIL
      FOR nCont = 1 TO Len( oKeys )
         oBrowse:SetKey( oKeys[ nCont, 1 ], oKeys[ nCont, 2 ] )
      NEXT
   ENDIF
   oBrowse:SetKey( K_BS, { | oBrowse, nKey | FazBrowseBackSpace( oBrowse, nKey ) } )
   oBrowse:RefreshAll()
   DO WHILE .T.
      DO WHILE .NOT. oBrowse:Stable()
         oBrowse:Stabilize()
      ENDDO
      nKey := Inkey(0)
      DO CASE
      CASE nKey == K_ESC
         EXIT
      CASE nKey > 31 .AND. nKey < Asc( "z" )
         FazBrowseAnyChar( oBrowse, nKey )
      ENDCASE
      oBrowse:ApplyKey( nKey )
   ENDDO
   SET SCOPE TO
   RETURN NIL

FUNCTION FazBrowseBackSpace( oBrowse, nKey )

   MEMVAR cFiltro

   IF Len( cFiltro ) > 0
      cFiltro := Substr( cFiltro, 1, Len( cFiltro ) - 1 )
      IF Len( cFiltro ) == 0
         SET SCOPE TO
      ELSE
         SET SCOPE TO ( cFiltro )
      ENDIF
      GOTO TOP
      oBrowse:RefreshAll()
   ENDIF
   HB_SYMBOL_UNUSED( nKey )
   RETURN NIL

FUNCTION FazBrowseAnyChar( oBrowse, nKey )

   MEMVAR cFiltro

   cFiltro += Upper( Chr( nKey ) )
   SET SCOPE TO ( cFiltro )
   GOTO TOP
   oBrowse:RefreshAll()
   RETURN NIL

[asimoes]

Acho que achei o problema:

No include hbcompat.ch

#xtranslate hb_SetKey( [<x,...>] ) => SetKey( <x> )

#xtranslate SetKey( [<x,...>] ) => hb_SetKey( <x> )

Eu uso xhb.hbc nas minhas compilações.

E no hbp

-u+hbcompat.ch

[asimoes]

É isso mesmo é esse translate:

#xtranslate SetKey( [<x,...>] ) => hb_SetKey( <x> )

Que estava gerando o erro.

O arquivo é hbcompat.ch

Isso é um problema, não acham? se usar hbcompat.ch em alguma rotina que use tbrowse e o método setkey vai dar erro por conta do translate.

[JoséQuintas]

Ué, mas tá confuso isso.

Código: Selecionar todos

#xtranslate hb_SetKey( [<x,...>] ) => SetKey( <x> )
#xtranslate SetKey( [<x,...>] ) => hb_SetKey( <x> )

Converte SetKey() pra hb_SetKey(), ao mesmo tempo que converte hb_SetKey() pra SetKey()
Isso não criaria um loop infinito?

Se converte um método :SetKey() não seria um bug?
porque pode converter muita coisa que não deveria além disso aí.
Reportando o possível bug.

[asimoes]

Tá com cara de bug na hbcompat.ch da xhb

[asimoes]

No hbcompat.ch tem um

#ifdef __XHARBOUR__

e o

#xtranslate SetKey( [<x,...>] ) => hb_SetKey( <x> )

está no

#else

Linha 296

[JoséQuintas]

Ok.
Reportei como bug.
Isso pode ser perigoso pra outras coisas, não somente para o :setkey()

Senão vamos ter que ficar olhando tudo que é arquivo .CH pra ver se interfere em alguma coisa...

[asimoes]

Este translate conflita na chamada do método setkey na função TBrowsenew.

[asimoes]

hbcompat.ch é para compatibilizar funções que trocaram de nome, mas pode como você disse Quintas, gerar um erro dificil de encontrar/solucionar.

No meu caso não posso usar o setkey por hora, porque toda aplicação usa hbcompat.ch por conta de try..catch e outras funções.
e ao invés de usar #include hbcompat.ch em todas rotinas eu já informo na compilação no hbp:

-u+hbcompat.ch

[JoséQuintas]

A resposta do Viktor é que ele sempre recomendou não usar hbcompat.ch, que é uma espécie de guebra-galho.

https://github.com/vszakats/harbour-cor ... -166612929

Reforcei que isso não se trata apenas do que contém hbcompat.ch, mas do #xtranslate poder afetar nomes de métodos.

Só descobrimos porque o hbcompat.ch usa isso.
Pra esse caso, não considero hbcompat.ch como problema, mas como um arquivo contendo um exemplo de #xtranslate que causa problema.
Mais uma coisa pra ficar de olho.

[JoséQuintas]

até que deduzi certo.

Vamos considerar o básico:
O nome do método é tbrowse:SETKEY()
O erro é não existir: tbrowse:HB_SETKEY()
Se não estiver no fonte, talvez possa ser possível algum arquivo .CH estar modificando.

Apesar do trabalho, um erro que é novidade pra todo mundo.
É difícil acontecer algo assim.
Mais difícil ainda ser causado por um arquivo do próprio Harbour.

É por isso que insisto: tem que simplificar fontes, pra ficar craque em coisas simples e básicas.
Ficando craque em coisas simples e básicas, o complicado que usa coisas simples e básicas também fica mais simples.
E a parte básica vale sempre, resolve qualquer coisa - até problema em método que usa codeblock dentro de uma classe!

[asimoes]

O Viktor não recomenda usar hbcompat.ch e o legado? tem que modificar todo o código quando a função muda de nome?
Nós usamos o hbc porque contém os includes e libs atualizados e de um único local como componentes e eu nem me atrevo a alterar para gerar erros em outras rotinas. Penso que se fez o translate tem verificar todo o código da lib o que pode gerar incompatibilidade. Tem muita gente que não olha os fontes do harbour, principalmente os recem chegados a linguagem. Quintas quando você mencionou algum ch alterado, imediatamente vasculhei os ch´s do harbour e achei o problema. Agora se não recomenda usar hbcompat.ch, o que usar então?

[JoséQuintas]

hbcompat.ch é pra aceitar compatibilidade com xHarbour, pra poder compilar fontes xHarbour.
Se decidiu pelo Harbour, não precisa mais compatibilidade.
Teria que verificar porque precisa dele.

Aliás... chega a alterar o comportamento do Harbour, o que pode deixar o programador incompatível... rs