ProcessMessages

[Guilherme Taso]

oi forum.
o que exatamente faz cada funcao e qual a diferenca entre elas?
1. GTprocessmessages()
2. wvw_processmessages()

[Stanis Luksys]

Fazem a mesma coisa.

Servem para que a janela processe os eventos padrões do Windows. Se você está dentro de um loop, você insere está função para que o programa continue processando eventos exeternos ao loop sob responsabilidade do SO.

Por exemplo, dentro de um do while que varre um arquivo de 50000 registros, se não colocar esta função o prgrama trava e qualquer toque com o mouse sobre a tela resultará em "Programa não respondendo" no WIndows, o que pode levar o usuário mal avisado a fechar o programa pelo Gerenciador de Tarefas. Na verdade, mesmo ele não respondendo ao windows, o processo está sendo executado, e com paciência, se esperar, ele ressucita.

Abraços.

[Maligno]

Uma pequena adição: cada programa Windows tem uma função em que as mensagens externas (de aplicações diferentes e/ou do Windows) e internas (forms da mesma aplicação) são executadas. Se algum processo do programa requerer mais atenção do SO, vai demorar bem mais para que o escalonador de processos do Windows seja desviado para a execução das mensagens pendentes. O resultado disso é, por exemplo, uma interface gráfica congelada, porque suas mensagens de atualização ainda estão na fila de pendências. Ao pedir manualmente que essas mensagens sejam processadas, essa fila anda e essa interface é então atualizada.

[Maligno]

Aliás, em tempo, um OFF-TOPIC útil:

Muita gente desconsidera esse que é um ótimo recurso. O Windows permite o uso de mensagens customizadas para troca de informações entre aplicações diferentes ou mesmo entre processos da mesma aplicação. Para isso basta criar um range próprio para suas mensagens privadas, a partir do que ele define como WM_USER (ou 0x400 até 0x7FFF), e incluir um manipulador. Certamente o [x]Harbour deve ter uma função própria pra isso.

Um exemplo da forma que uso: no cadastro de notas fiscais tenho a inclusão do cliente. Uma tabela à parte pode ser consultada através de um form próprio pra isso, e se for selecionado um cliente, o que faço é apenas copiar seus dados para algum lugar da memória e emitir uma mensagem para que a rotina chamadora, sela ela qual for, pegue o ponteiro repassado com a mensagem. A partir dele é só ser a string com os dados (no formato de arquivos INI: NAME=VALUE) e preencher os campos necessários. Após o uso o ponteiro é destruído e a memória fica limpa. A abstração é total. A função de seleção nada sabe de quem a chamou e a função chamadora nada sabe de quem foi chamado.

[alxsts]

Olá!

Interessante!

As funções citadas não são do xHarbour. Teria algo que faça o mesmo papel em xHarbour?

[Stanis Luksys]

Olá,

As funções citadas não são do xHarbour. Teria algo que faça o mesmo papel em xHarbour?

As duas funções são de bibliotecas do xHarbour, uma da HBGT, e outra, que cumpre o mesmo papel, na GTWVW.

Todas as bibliotecas gráficas para (x)Harbour possuem funções semelhantes.

Abraços

[alxsts]

Olá!

Obrigado Stanis.

Eu percebi que não são do próprio xHarbour.

Quer dizer que se eu não usar lib gráfica, não tenho esta opção?

Teria algo que faça o mesmo papel em xHarbour?

[Stanis Luksys]

Olá,

Me parece que por padrão o Harbour adiciona alguma gt em Linux e Windows janelado, mas não tenho certeza... De qualquer forma, em modo "console puro" (ex: DOS, XTERM, NTVDM) você não precisará de uma função que faça este trabalho, uma vez que o ambiente é monotarefa ou emulado para ser.


Abraços.

[Itamar M. Lins Jr.]

Ola!

De qualquer forma, em modo "console puro" (ex: DOS, XTERM, NTVDM) você não precisará de uma função que faça este trabalho, uma vez que o
ambiente é monotarefa ou emulado para ser.

Está equivocado. O Harbour tem função equivalente o xHarbour também. Acredito não haver relação se é console ou não.
Podemos usar no "Do While", "For Next", etc...
Usamos por exemplo; inkey(0.1) dentro "Do While"

HB_IdleSleepMSec()
Queries or changes the default time interval for idle task processing.
Syntax
HB_IdleSleepMSec( [<nNewInterval>] ) --> nOldInterval

Arguments
<nNewInterval>
This is a numeric value specifying the time interval to wait between the execution of idle tasks. The unit is 1/1000th of a second (milliseconds). The default value is 20. Return
The function returns the previous wait interval for idle tasks as a numeric value.
Description
Function HB_IdleSleepMSec() queries or changes the number of milliseconds after which the next idle task is executed. This allows for fine tuning idle task processing and to optimize CPU usage on multi-user systems, such as Terminal Server, where a minimum amount of idle task processing is desirable.

Tem outra no Harbour mas não lembro agora.

Saudações,
Itamar M. Lins Jr.

[Stanis Luksys]

Ok,

Mas ao que me parece a HB_IdleSleepMSec() não tem a mesma intenção da gtprocessmessage(), pois que senão, sendo ela nativa, não haveria necessidade de existir mais tantos outros translates pra cada lib gráfica, Acho que em uma você define o intervalo de tempo para execução de tarefas penduradas na fila, como o maligno explicou lá em cima, e a outra visa processar eventos de tela da própria janela do programa. Não seria isso?

Me lembro que a minigiu tinha um comando DO EVENTS que fazia isso também.

Mas é claro que você está certo ao dizer que é um recurso a ser usado mesmo em console puro no Windows. Em DOSou NTVDM por exemplo, que foi o meu exemplo de console puro, não faria efeito, no máximo deixaria o programa mais lento.

Eu já usei a HB_IdleSleepMSec(), e ela foi justamente colocada num translate dentro do inkey porque o load ia as alturas num sistema Unix (HP-UX) toda vez que parava no inkey(0). Talvez hoje ela já esteja dentro do inkey, pelo que entendi.

[Maligno]

sendo que em uma você define o intervalo de tempo para execução de tarefas penduradas na fila, como o maligno explicou lá em cima

Não é bem isso. ProcessMessages() como padrão (e seja o nome que tiver), nem argumento tem. É apenas uma forma de fazer a fila de mensagens "andar" quando no meio de uma carga pesada de processamento. Não se compara à qualquer manipulação de "idle cycle", que é um conceito que veio do Clipper. No [x]Harbour, imagino, só serve mesmo para compatibilidade. Espero que sirva só pra isso. ))

[Stanis Luksys]

É Maligno,

Mas não podemos esquecer que o xHarbour roda em DOS também, apesar de qua acho muuuito improvável que tnha louco fazendo isso. Pois oras, se for pra rodar o SO inteiro em console puro melhor usar no Unix ou Linux com todos os recursos modernos do SO.

[Maligno]

Mas qualquer programa Windows não-GUI pode rodar em uma janela DOS (console) também. Não por isso se deixa de usar ProcessMessages(). O fato é que o [x]Harbour não gera aplicativos de 16, mas de 32 bits. Mesmo com sintaxe totalmente "clipper-like" o programa será Windows. Por isso que disse que a manipulação do "idle cycle" só deve existir mesmo para efeito de retrocompatibilidade. Em programas mais modernos, livres do "peso" do legado do Clipper, nem se deveria cogitar usar funções desse tipo. Minha opinião.

[mhackervix]

Ola!

De qualquer forma, em modo "console puro" (ex: DOS, XTERM, NTVDM) você não precisará de uma função que faça este trabalho, uma vez que o
ambiente é monotarefa ou emulado para ser.

Está equivocado. O Harbour tem função equivalente o xHarbour também. Acredito não haver relação se é console ou não.
Podemos usar no "Do While", "For Next", etc...
Usamos por exemplo; inkey(0.1) dentro "Do While"

A função Inkey() (ou MilliSec() do xHabour) é distinta da função ProcessMessage() em sua aplicação. Enquanto a Primeira "devolve o Processamento" por alguns milesimos de segundos a Segunda função solicita ao Windows que atualize a Janela da Aplicação (Lista de Mensagens). Utilizamos a primeira quando não queremos que um loop grande consuma muito processamento interfirindo no desempenho geral do sistema (execução de outras aplicações). Já a Segunda é utilizada quando necessitamos de uma atualização da janela do aplicativo, pois em um loop "grande" pode ocorrer que as mensagens colocadas na janela durante a execução parcial deste só se apresentem no final do loop, fazendo que uma contagem de 0% a 100% (por exemplo) se apresente pulando do 0 para o 100% de uma vez, assim, o ProcessMessage() é chamado apos as atualizações da janela para garantir a apresentação.

A confusão esta no fato que quando utilizamos uma função como o MIlleSec() e devolvemos processamentoa ao SO este tambem faz a fila de mensagens "andar" e quando utilizamos uma função como o ProcessMessage(), por ser uma chada ao sistema esta tambem devolve processamento ao mesmo.


att.

[Maligno]

a Segunda função solicita ao Windows que atualize a Janela da Aplicação (Lista de Mensagens)

Não é bem isso. Mas quase. ProcessMessages (ou seja lá o nome que for) tem for função "desafogar" a fila de mensagens, onde podem constar mensagens dos mais variados tipos. Inclusive, mensagens destinadas às atualizações para o formulário. Um clique de botão, um arrastar de mouse, etc. Qualquer coisa no Windows gera mensagem. E são milhares delas a cada instante. Todas com a sua importância para a aplicação.

Particularmente, eu quis dizer que as funções de manipulação do "idle cycle" são um legado do tempo do Clipper, desnecessárias se não houver mais obrigações com esse legado. Elas não são necessárias em programas modernos. A não ser que (meu conhecimento sobre [x]Harbour é limitado) o [x]Harbour, em função de sua própria arquitetura interna (talvez também (limitada e) vinculada ao legado Clipper), exija o uso de recurso do tipo, assim como em muitas ocasiões o Clipper exijia. Aí a história é outra.