Erro inexplicável voltou

[JoséQuintas]

Error BASE/44 Assigned value is wrong class: ...
Called from (b)...
(1) = Tipo: N Valor: 0

Sei lá....
Acho que vou ter que criar uma callstack pra API do Windows.
Deve ser alguma mensagem da API windows sem tratamento adequado.
Mas se o erro poderia ser até nisso.... complica....

[Fernando queiroz]

Quintas tive muitos erros assim quando tinha mistura de bibliotecas gráficas.
despois que passei a usar somente a HWGUI não tive mais

[JoséQuintas]

Eu não misturo, mas uso a parte que criei.

API Windows entra num jogo de empurra-empurra entre Windows e aplicativo pra encontrar solução.
O aplicativo precisa dizer se é pra parar ou pra continuar o empurra-empurra.
Deve ter alguma mensagem com erro nisso.

Na outra época encontrei algumas com retorno errado.
Não basta fazer o que precisa, precisa avisar o windows que já fez, ou que é pra desprezar.

[clodoaldomonteiro]

Bom dia, Quintas.

Você está usando uma .LIB para o TBrowse() ou está anexando os fontes .PRG dele no seu projeto, pois se caso a segunda opção, teria como vc ir depurando o que está acontecendo com o uso dele.
Aqui tive um problema com o Browse(), que era causado por uma torina que tinha para armazenar a string do Filtro, que em algum momento extrapolava e retornava truncada, mas tive que nos fontes do TBrowse() ir registrando tudo em arquivo, para q eu pudesse analisar.

Outra coisa que percebi, são as diferenças da Classe Tbrowse() mas as diversas versões do xHarbour e Harbour e nos fontes que tenho, não entrei nada referente a ":CSepColor".
Abraços.

[JoséQuintas]

No caso de erro em API Windows, a mensagem de erro não é importante.
Postar a mensagem sempre causa confusão.
O Windows FECHA PARTE DO APLICATIVO sem que o harbour possa prosseguir corretamente.

A única parte visível é a final, onde o retorno é ZERO.

[clodoaldomonteiro]

Vi aqui: https://github.com/harbour/core/pull/185/files , que cSepColor deve ser uma string (Caracter) e o valor que a mensagem retorna diz que foi passado um inteiro de valor "0".
Mas depende muito da ver do Harbour/xHarbour.

Código: Selecionar todos

//Fonte extraído de: https://github.com/harbour/core/pull/185/files
   VAR    cSepColor  AS CHARACTER               // heading/column/footer separator color
   METHOD nTop( nTop ) SETGET                   // get/set top row number for the TBrowse display
   METHOD nLeft( nLeft ) SETGET                 // get/set leftmost column for the TBrowse display
   METHOD nBottom( nBottom ) SETGET             // get/set bottom row number for the TBrowse display

Daí é ver como está seus fontes, e ver se essa variável recebeu um valor Integer, acho eu.

Abraços.

[JoséQuintas]

Daí é ver como está seus fontes, e ver se essa variável recebeu um valor Integer, acho eu.

Apenas pra complementar, mas já falamos por zap:
Minhas funções de cores são fixas.
Elas SEMPRE retornam STRING, sem tratamento, sem pesquisar, sem IF, aconteça o que acontecer, é sempre a MESMA STRING FIXA NO FONTE.
Por exemplo, se fosse azul, FUNCTION CorAzul(),; RETURN "W/B".
Não tem como isso retornar ZERO, é só mesmo quando acontece esse bug inexplicável.

Certa vez eu vi uma mensagem do windows sobre limite de recursos excedidos.
Por isso relaciono o problema a algum problema no uso de API Windows.

ACHO, não tenho certeza, que API Windows trabalha estilo recursividade, chamadas a si mesmo.
Então, ACHO que uma ou mais ficaram infinitas por falta de tratamento.

E isso usa multithread, o Windows não espera que uma termine antes de chamar outra.
Então, apesar do programa continuar funcionando, essa outra rotina sem fim continua.
E quando estoura o limite, é quando o programa "endoida".
A mensagem de erro é nesse "endoidamento", mas não é esse o erro.

Vamos comparar com CDX corrompido.
A mensagem de CDX corrompido aparece numa determinada parte do fonte.
Isso não significa que aconteceu nessa parte do fonte, aconteceu antes, mas só foi dar erro depois.

Com o erro inexplicável acontece o mesmo.
Só que ao contrário do CDX, não é detectado, e é justamente com toda tabela interna do harbour.

"Talvez" um aplicativo normal se feche, e com multithread continue.
Nesse caso multithread não é o problema, ao contrário, apenas acabou deixando ver que o problema aconteceu.

Simular um erro desse tipo é até relativamente fácil.

Código: Selecionar todos

PROCEDURE Main
LOCAL a := 10
CLS
hb_ThreadStart( { || Show(a) } )
Inkey(1)
RETURN

PROCEDURE Show(a)

hb_gtReload( "WVG" )
CLS
Inkey(2)
? a + 10
RETURN

Isso vai dar erro.
O harbour vai encerrar e destruiir a variável A, mas mesmo assim Show() ainda vai ser executado e vai tentar usar a.