Página 2 de 2

Visualizar arquivo no video - vai alem 64k

Enviado: 10 Jul 2011 01:01
por fladimir
Também achei muito estranho, tanto q qdo um de meus técnicos comentou q um cliente estava com esse tipo de problema q lembrava da época q usava o clipper sem o FreTSlice, achei muito estranho e fui conferir e realmente no Windows XP ocorre, mas no Windows 7 ou Vista não ocorre, ai postei a dúvida, pois analisei o código e nem achei q o Inkey(0) poderia estar relacionado, pq em alguns locais do meu sistema utilizo o Inkey(0) e não percebi este problema.

Mas o fato é q o código acima em Harbour comigo com Inkey(0) eleva now WINDOWS XP o Processamento a Níveis muito elevados, amarrando a máquina.

E foi resolvido mudando ele para 0.2 ao invés de ZERO.

Sds.

Sucesso!!!

Visualizar arquivo no video - vai alem 64k

Enviado: 10 Jul 2011 01:47
por alxsts
Olá!

Isso me faz lembrar Zé Ramalho, em "Mistérios da Meia Noite"...

Só pra dizer que o "0.2" foi o que me veio na hora. Também pode ser outro valor, como 0.1, 0.002, etc. O que importa é que o processador tenha uma folga para olhar para outras tarefas e atendê-las. Enfim, é o típico Do Events do Visual Basic.

Visualizar arquivo no video - vai alem 64k

Enviado: 10 Jul 2011 08:13
por Maligno
Essa falta de folga para o processador por meio do Inkey() provavelmente faz a VM (tentar) uma reorganização de memória e/ou limpeza de lixo que não está funcionando. Essa análise bate com o Clipper, mas não deveria ocorrer no [x]Harbour. A não se que na versão em questão exista um UDB (Unidentified Damn Bug)¹. Aí é outra história.




¹ EMNI - Erro Maldito Não Identificado.

Visualizar arquivo no video - vai alem 64k

Enviado: 12 Jul 2011 20:38
por janio
Com xharbour 1.2.1 inkey(0) não leva o processador as alturas.

Acabei de testar.

Janio