GET com temporizador

[Eolo]

Pessoal,

To migrando do Clipper52e pro XHarbour, sem LIB visual, e preciso do que se segue...

Um usuário navega num TBrowse e, sobre o registro X, tecla ENTER para editá-lo. Meu programa então bloqueia o registro e abre os respectivos campos numa outra tela. O usuário altera o que precisar, grava as alterações e, na saída, o registro é UNLOCKado. Aí aí, baba. O problema é o que o usuário "esquece" essa tela aberta e então o arquivo fica "amarrado", até que o usuário saia da edição...

O que eu imagino que preciso: alterar o GETSYS, na parte onde ele captura as teclas pressionadas, trocando o inkey(0) por um inkey() e controlando o tempo dentro do loop: se o usuário não teclar nada por X tempo, o READ é abortado, então UNLOCKo o regisrto e volto o controle pro TBrowse.


Ah, no TBrowse vai ser a mesma coisa, mas isso eu já resolvi: se o usuário deixa a tela aberta, rodando sem necessidade, depois de X tempo (sem que o usuário tecla alguma coisa) ele é encerrado...

[Stanis Luksys]

Opa,

Eu tenho essa alteração no getsys em algum lugar por aqui. Inclusive lembro que ela é abordada no segundo livro da série do Ramalho. O read "temporizado".

Se eu achar eu aviso.

Falou!

[Eolo]

Stanis,
No Clipper, baba, tá na folha. Mas e no Xharbour?

Leonardo,
Dei uma olhada nos arquivos que tu me mandaste mas, putz, não consegui sair do lugar. Eu tentei achar algum inkey(0) no meio deles, pra controlar a coisa a partir daí, mas não achei... Bah, devo estar no caminho errado, tchê!

[sygecom]

Eolo, vice... será que tem que ser pelo read do GETSYS ? quem sabe um WHEN com um valid....será que não ficar 10zzz ?

[Eolo]

Leonardo, não caiu a ficha aqui... Como uma função chamada pelo VALID vai controlar o tempo? Acho que não saquei.

[Maligno]

Ele quis dizer colocar uma função de temporização pra executar em cada WHEN de cada campo. Dá um pouco de trabalho, principalmente se forem muitos campos, mas dá pra modificar o comando GET pra deixar isso embutido.

[Maligno]

De tanto que trabalhei, meus miolos estão meio derretidos. Esquece o que eu disse: por WHEN não dá. Nem por VALID. Teria que alterar o GETSYS, obrigatoriamente.
Se no XHarbour for parecido com o que se tem no Clipper, é só colocar um temporizador na função que chama o aplicador. No Clipper, seria:

Código: Selecionar todos

// Apply keystrokes until exit
WHILE ( oGet:exitState == GE_NOEXIT )
   GetApplyKey( oGet, inkey( 0 ) )
ENDDO

Seria só trabalhar em cima disso aí. E, claro, alterar o comando READ para aceitar uma configuração de temporização. Mas nem dá tanto trabalho.

[Eolo]

Sim, no Clipper parece simples... É só trocar o inkee(0) por inkey() e ficar monitorando o tempo. Mas e no XHarbour? Num achei o Getsys...

[Maligno]

Mas e no XHarbour? Num achei o Getsys...

Bom, aí eu passo. Não tenho a menor idéia de como seja. Não há algo mais ou menos parecido?

[esbasso]

Eu uso assim no XHARBOUR sem ter de mexer em nada

antes dos get
keysec(254,INT(60),- 1,.t.) && 60 segunods
SET KEY 254 TO Fechar_get

...
..
comandos
..

para desativar no fim

keysec()



FUNCTION fechar_get

IF EMPTY(READVAR())
KEYB CHR(27)
ELSE
KEYB CHR(27)+CHR(27)
ENDIF

RETURN

[Maligno]

Não conheço essa função, mas imaginava algo mais "enraizado", como por exemplo: READ KILL IN <n> SECS. Mas se sua dica funciona, já é uma ajuda pro colega.

[sygecom]

Eolo, o colega esbasso matou a charada com o exemplo que ele postou.
Assim que der vou dar uma olhada no GETSYS.PRG do xharbour...e realmete pelo WHEN não daria...minha idéai era iniciar um contador junto com GET, mas o GET não executa o WHEN enquanto não sair dele !!! :(Neg :(Neg

Abraços
Leonardo Machado

[Stanis Luksys]

mas o GET não executa o WHEN enquanto não sair dele !!!

Na verdade o WHEN é executado assim que o objeto GET ganha foco, o VALID sim é executado ao sair do GET. De qualquer forma o temporizador não poderia ser aplicado a nenhuma das duas cláusulas, e sim diretamente no tratamento que o comando READ faz a lista de GETs pendentes, que foi o que o colega postou acima.

Note que no exemplo dele, a função é executada de qualquer maneira, e abandona o READ avaliando se os GETs da sua lista de pendência permanecem inalterados. Ou seja, sempre, afinal a gravação ainda não foi executada.


Falou!

[Eolo]

Esbasso, essa sua função sempre vai derrubar o READ depois de 60 segundos, independentemente do usuário ter teclado alguma coisa, certo?

Bão, embora seja um tempo razoável, eu gostaria de fazer o mesmo que fiz no TBRowse (ou seja, o tempo ficando ligado à inatividade): na entrada, eu marco o horário e, a cada loop, vejo se já se passaram 60 segundos. Se sim, EXIT. Só que, a cada loop, eu reinicio a "hora de entrada" quando o usuário tecla qq coisa... Por ex, se o cara teclar SETA ACIMA aos 59 segundos, o tempo é reiniciado...

Então, pergunto se isso seria possível no GET:
- se o usuário não digitou nada (em nenhum dos GETs), sai em 60 segundos sem dizer tchau;
- se ele digitou qq coisa mas está inativo há 60 segundos, bota um aviso na tela ("Processo sendo encerrado por inatividade...") e dá 5 segundos pro usuário se manifestar... Se nada for digitado, tchau (mesmo perdendo alterações não salvadas).

[Maligno]

Então, pergunto se isso seria possível no GET

Neste caso o problema passa a ser outro. Você precisa identificar se houve ou não alguma alteração. De duas uma: ou você compara seus campos um a um ou você faz como eu, que uso apenas matrizes para armazenar esses campos. Antes do GET, meu GETSYS armazena o CRC32 da matriz toda (convertida pra matriz). Ao sair, ele recalcula e compara com o valor armazenado. Se iguais, sai sem aviso, gravação, etc.