Página 1 de 1

Erro esquisito

Enviado: 09 Jun 2016 10:57
por JoséQuintas
Este é um tipo de erro que nem tem o que fazer, muto esquisito.
Error BASE/1003 Variable does not exist: SELF
Called from (b)FAZBROWSE(566)
Called from DBSEEK(0)
Called from AUXLICOBJCLASS:ESPECIFICO(71)
Called from AUXLICOBJCLASS:EXECUTE(372)
Called from PAUXLICOBJ(21)
Called from DO(0)
Called from RUNMODULE(119)
Called from BOXMENU(886)
Called from BOXMENU(865)
Called from MENUPRINC(733)
Called from SISTEMA(160)
Called from (b)MAIN(82)
Parece um erro básico, mas não é.

1. FazBrowse() uso por todo o aplicativo, pra tudo que é browse (dbEdit), presente em todo lugar pra tudo.
2. Checagem de variáveis uso -w3 -es2, não passa nenhuma variável que não exista
3. SELF é da classe, pra retornar ela mesma

Nunca vi esse erro numa coisa dessas.
Considerando que a rotina é pra TUDO, tá lá há anos, dar esse erro depois de milhares de usadas... é esquisito.
Até dei uma olhada no fonte, mas nem tem isso lá. (pelo menos agora).

Só vai ficar como um erro esquisito, não há o que fazer.
De repente, vai demorar mais um ano pra acontecer de novo.... rs

Lógico... vou acabar atualizando versão. Se algum dia acontecer de novo, pelo menos a linha do fonte vai bater.... rs

Erro esquisito

Enviado: 09 Jun 2016 11:23
por JoséQuintas
Esqueci que é classe, mas não resolveu

Código: Selecionar todos

METHOD Especifico( lExiste ) CLASS AUXILIARClass

   LOCAL GetList := {}
   LOCAL maxCodigo := jptabel->axCodigo

   IF ::cOpc == "I"
      maxCodigo := "*NOVO*"
   ENDIF
   @ Row()+1, 20 GET maxCodigo PICTURE "@K 999999" VALID NovoMaiorZero( @maxCodigo )
   Mensagem( "Digite código, <F9> pesquisa, <ESC> volta" )
   READ
   Mensagem()
   IF LastKey() == K_ESC .OR. ( Val(maxCodigo) == 0 .AND. maxCodigo != "*NOVO*" )
      GOTO ::nUltRec
      RETURN .F.
   ENDIF
   SEEK ::cTabelaAuxiliar + maxCodigo // <<--------------------- linha 71
   IF .NOT. ::EspecificoExiste( lExiste, Eof() )
      RETURN .F.
   ENDIF
   ::axKeyValue := { maxCodigo }
   RETURN .T.
Segundo o log de erros, esse seek chamou o fazBrowse()

Alguém consegue explicar?

Erro esquisito

Enviado: 09 Jun 2016 11:39
por JoséQuintas
Só comentário.... da doidera....

A classe pAuxLicObj é pra licenças, objetos que tem licença, recebe por herança a classe AuxiliarClass

A classe AuxiliarClass é genérica pra cadastros auxiliares, recebe por herança a classe frmCadastroClass

A classe frmCadastroClass é genérica pra cadastros, recebe por herança a classe frmGuiClass

A classe frmGuiClass é genérica pra cadastros, cuida do visual

Só, para por aí... rs

Erro esquisito

Enviado: 09 Jun 2016 12:31
por Kapiaba
Bom dia, o que tem na linha: 566?

Código: Selecionar todos

Called from (b)FAZBROWSE(566)

Código: Selecionar todos

PUBLIC Self
Não resolve?

Erro esquisito

Enviado: 09 Jun 2016 17:15
por JoséQuintas
Pensei numa possibilidade:
como o erro é no SEEK, pode ser algo relacionado ao save/restore do filtro, alterado pela FazBrowse().
Pelo conteúdo da linha 566, o fonte não bate com o erro.

Erro esquisito

Enviado: 09 Jun 2016 17:32
por Ricardo C. Freitas
Boa tarde,


Você sabe qual o conteudo de "::cTabelaAuxiliar"


At+

Erro esquisito

Enviado: 09 Jun 2016 17:53
por JoséQuintas
Consegui gerar o erro na minha máquina, com o último fonte:
O erro foi realmente no seek, a linha que vém depois é apenas a indicação de onde foi feito o SET FILTER.
Como já mexi no fonte, a linha indicada antes não era do SET FILTER.

Código: Selecionar todos

   SET FILTER TO jptabel->axTabela == oFrm:cTabelaAuxiliar
Solução:

Código: Selecionar todos

SET FILTER TO &( "jptabel->axTabela == [" + oFrm:cTabelaAuxiliar + "]" )
Explicação:

Agora o filtro usa uma string, e não precisa de nenhuma variável. ( jptabel->axTabela == "LICOBJ" )
Não serve codeblock, porque o FazBrowse() pode colocar filtros adicionais.
E como a variável era da classe, o set filter original havia sido traduzido pra self:cTabelaAuxiliar ou algo assim.
O SEEK acaba acionando a checagem do filtro, o que causou o erro.

Nota:
isso de &( ) é interessante, pois a macro é feita sobre o resultado da expressão, acaba não dependendo das variáveis para o filtro.
melhor do que ficar brigando com variáveis.

Erro esquisito

Enviado: 09 Jun 2016 18:37
por JoséQuintas
Faltou dizer:

O problema estava na classe recebida por herança, AuxiliarClass.
E só acontecia no segundo acionamento da pesquisa em seguida ( justamente por estar usando um filtro "restaurado" )

Aproveitei pra dar uma geral em todos os SET FILTER, tinha mais alguns assim.