PC Toledo

Qual a diferença?
Por exemplo, o usuário teclando PageDown várias vezes seguidas.
Pra que atualizar a tela em cada PageDown, mais rápido atualizar só no final.

Explicando: Na parte acima, só atualiza enquanto não for teclado nada.
Nessa parte, só se o tbrowse estiver atualizado é que entra (se não está, é porque foi teclado algo, então que diferença faz atualizar a tela)

O próprio tbrowse já faz o controle sobre atualizar ou não a tela.
O que esta rotina faz é apenas não atrapalhar isso.

A tela representa vários registros do arquivo, precisa percorrer alguns registros pra fazer a atualização dela.
Não atualizar a tela economiza esse tempo de processamento.
E o registro atual não é definido pela tela, mas sim pelos controles internos do tbrowse.

Detalhe para a parte de código: oBrowse:ColorRect() .
Caso use a rotina padrão, troque por oBrowse:RefreshCurrent(), mas sem eliminar o inicial.

Só pra lembrar:
O primeiro oBrowse:RefreshCurrent() é pra DESMARCAR a posição anterior.
O segundo oBrowse:RefresshCurrent() ou oBrowse:ColorRect() é pra MARCAR a posição atual.
O erro nesses detalhes é que causam cores bagunçadas no tbrowse.

Nota:
Talvez no caso da navegação usar SET FILTER se perceba ainda mais, só testando.
Se pra atualizar a tela precisa navegar no arquivo, seriam alguns SKIP economizados.
Lembrando que a aceleração é no caso, por exemplo, de digitar PageUp/PageDown rápido, antes da tela ter sido completamente atualizada.
Nesse caso, já obederia o comando imediatamente, e a atualização de tela ficaria pra próxima pausa.

Nota2:
De quebra, o Inkey() ajuda a não mostrar o programa como travado em ambiente GUI.
E se for no Clipper, e usar OSLIB, pode ser interessante adicionar OL_Yield() no DO WHILE, já que libera tempo para o Windows acessar os dados em disco/na rede.
Em Clipper eu colocava OL_Yield() em todos os locais possíveis que poderiam ajudar o Windows, incluindo trocar Inkey() por MyInkey(), e a função já resolver tudo de uma vez.

Olá!

Em 2010, trabalhava em uma empresa que usava aplicativos xHarbour em servidores HP UX. Usando o comando TUSC, fizemos um teste de Inkey() dentro de DO...WHILE e percebemos como isto "martela" os processadores. Abolimos esta prática...

Duas funções que ajudam TBrowse são DispBegin() antes e DispEnd() depois da estabilização. Normalmente, não se faz estabilização após o método refreshCurrent(). Apenas após métodos que movem o ponteiro da fonte de dados.

Em Clipper eu usava isto:
Com isso mostrava 0% de uso de CPU no Clipper.

No Harbour não verifiquei, achei que era automático.
Já no VB6 tinha um DoEvents() pra situações desse tipo, com ou sem checagem de tecla.

Olá!

Também usei bastante este tipo de construção em Clipper.

Acho que me expressei mal: quando escrevi "martela", não quis dizer que o consumo de CPU chega aos 100%. O Harbour e xHarbour tratam isto automaticamente mesmo. Quis dizer que o processador fica "louco". Com Inkey(), imagine, em um milésimo de segundo, quantas vezes ele tem que interromper o fluxo de processamento para "perguntar" ao teclado se o usuário teclou algo. Claro que em alguns momentos temos mesmo que monitorar o teclado mas, creio que o mais indicado seja usar NextKey(). Lembrando que Inkey() e NextKey() só funcionarão em modo console.

O tópico Tecla de Abortamento tem alguns comentários sobre a parte gráfica, usando HMG. Certamente existe alguma maneira de interceptar uma entrada de teclado durante a estabilização de um TBrowse ou outro tipo e grid que a HMG forneça. Provavelmente todas as bibliotecas gráficas tem sua maneira particular para se conseguir este resultado.