clodoaldomonteiro escreveu: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.