Cancelar Operação

[Jairo Maia]

Olá José,

Só para encerrar por hoje:

Então o WHEN é antes de chegar no get.

Penso e trato WHEN como uma condicional para colocar o Get em Foco. Se a condição de WHEN não for atendida, o Get não entra em foco. Então, se a condição em WHEN foi atendida, o Get entra em foco. Eu penso assim... mas...

[JoséQuintas]

Olhei aqui, e vai complicar.

No caso de up/down, o controle é +1 ou -1, pra fazer os testes.
Isso faz com que o contador esteja no GET antes do WHEN.

Teria que alguém testar no Clipper 5.3.

No 5.2, que é o que tenho, o mouse ainda não existia.
Como eu que fiz as alterações na getsys pra mouse, não são do Clipper, e não serve de referência, porque não lembro se copiei do 5.3.

Na minha tá assim:

Código: Selecionar todos

   IF (nEXITState == GE_MOUSEHIT)
      nMRow := MROW()
      nMCol := MCOL()
      for nCont = 1 to Len(GetList)
         IF nMRow == GetList[nCont]:Row .AND. nMCol >= GetList[nCont]:Col .AND. nMCol <= ( GetList[nCont]:Col + GetLen(GetList[nCont]))
            IF GetPreValidate(GetList[nCont])
               nPos := nCont
               nEXITState := GE_MOUSEHIT
            ENDIF
         ENDIF
      NEXT
   ENDIF

Na minha também mostraria o campo errado (ou certo).
E seria mais perigoso deixar igual ao teclado, do que manter assim.

O melhor negócio é acabar com READVAR() como referência no WHEN pra não ter surpresas.

Aliás... não imagino porque usar ReadVar() no WHEN.
Talvez com um exemplo, possamos ver uma alternativa.

[asimoes]

Quintas e Jairo,

Sei que o fórum é CA-Clipper mas os testes que eu estou fazendo são em harbour 3.4, o meu clipper está compactado com senha e perdi a senha, hehehe. :)Pos
Obs.: eu uso a getsys padrão do harbour.

[JoséQuintas]

Aqui também é Harbour 3.4

É que a GETSYS que uso é a mesma que usava nos tempos do Clipper, talvez com alguma mudança posterior.

E antes do Harbour eu usava o Clipper 5.2, que não tinha funções pra mouse próprias.

O mouse só passou a fazer parte do Clipper na versão 5.3.

É que se no Clipper for igual, não é considerado bug, e vai continuar igual no Harbour.
A compatibilidade com Clipper só é abandonada em casos extremos, mesmo se for bug.

Até esqueci que aqui é Clipper, mas tá valendo tudo.

Por falar nisso... até mesmo classes, como deu pra ver na GETSYS.
Já existia classe no Clipper, só não estava liberada para o usuário, mas isso pode ser feito com biblioteca adicional, ou talvez arquivo CH.

[asimoes]

Quintas eu abri o fonte getsys.prg na pasta rtl veja esse ifdef, tem outras funções que não são do clipper, usar o mouse tem que ter cuidado, quando for verficar conteúdo de campo. Outra coisa o problema não é só no when o valid acontece a mesma coisa usando o mouse.

Veja o código, hb_isobject não é do clipper mesmo!

Código: Selecionar todos

#ifdef HB_COMPAT_C53
PROCEDURE GetApplyKey( oGet, nKey, oGetList, oMenu, aMsg )

   IF ! HB_ISOBJECT( oGetList )
      oGetList := __GetListActive()
   ENDIF
#else
PROCEDURE GetApplyKey( oGet, nKey )

   LOCAL oGetList := __GetListActive()
#endif

[JoséQuintas]

É um detalhe interessante: No Clipper 5.3 o GET também atende MENUs e outras coisas mais, como deu pra perceber aí nos parâmetros.

O uso de HB_ISOBJECT() é só pra testar se existe GetList
No Harbour, tem a GetSys baseada diretamente em classes.
Mas ainda funciona a mesma do Clipper.

[asimoes]

Quintas,

Bom dia,

Tem como você testar o uso do mouse/teclado com a sua getsys e ver se tem o mesmo comportamento quando mostra a ReadVar() ?

Código: Selecionar todos

FUNCTION ReturnValue( xValue, ... )
   hb_alert(ReadVar())
   RETURN xValue

[JoséQuintas]

Nem precisa já postei o fonte, olhando o fonte já se vê isso.

Código: Selecionar todos

 IF GetPreValidate( GetList[ nCont ] ) 
                nPos := nCont 

o GetPreValidate() seria o WHEN.
E o nPos seria o GET onde foi feito o click - o próximo get.
Significa que o WHEN está posicionado em qualquer campo anterior quando é mouse.

Já quando é teclado, é usado nPos + 1 ou nPos -1, e só depois é verificado o WHEN (GetPreValidate()).

Simplificando é assim:
faz mais de 20 anos que acontece isso.
Em 20 anos muitos fontes foram feitos.

No caso do Clipper é aceitar.
No caso do Harbour, também, pelo motivo acima.

Vai de cada um, se quiser diferente, criar sua própria Getsys diferente.

Supondo que faça igual o mouse:

Código: Selecionar todos

@ 1, 0 GET a
@ 2, 0 GET b WHEN GetShow()
@ 3, 0 GET c WHEN GetShow()
@ 4, 0 GET d WHEN GetShow()
@ 5, 0 GET e WHEN GetShow()
READ

FUNCTION GetShow()
   @ 1, 0 SAY ReadVar()
   RETURN .T.

No fonte acima. Se teclar seta pra cima, que nome deveria aparecer em cada WHEN?
Percebeu?
O conserto pode se transformar em problema.
Talvez no Harbour, na versão de Getsys em classe, isso esteja resolvido por ser exclusivo do Harbour e não precisar compatibilidade.

Resolvendo isso de forma prática:
Porque verificar variável sendo digitada na cláusula WHEN, se nesse ponto nenhuma variável está sendo digitada?
Usar o Readvar() aí é que está errado.

[asimoes]

Acredito que ReadVar() possa ser desnecessário mas existe um erro e que pode ser consertado.

[microvolution]

gente boa tarde!
Não sabia que uma simples resposta minha, gerou este alto nível de professores se dissertando entre si... fiquei 2 dias ser ver o post e deu 3 páginas de discussão.
vlw ReadExit(.t.) setas pra cima/baixo. Obrigadooooooooooooooooooooo!!! :-O

[JoséQuintas]

Pois é, estamos redescobrindo o Clipper... rs

ASimões:
A primeira questão é: e o que seria consertar? o que considerar como correto?

Nesse exemplo que postei:
No teclado, o WHEN vai ser executado pra cada GET que tenha WHEN durante o "pulo".
No mouse, o mouse pula direto pra outro GET e só é executado um único WHEN.

A própria lógica de funcionamento é diferente.
Sei que eles não vão alterar, e se fosse eu também não alteraria.

Aqui mesmo, nem vou me preocupar com isso, porque não uso ReadVar() no WHEN, só no VALID.

Seria reinventar toda getsys, só pra resolver algo à primeira vista inútil.
Correndo o risco de estragar tudo tentando encontrar solução.

[asimoes]

Então deixa do jeito que está.

[JoséQuintas]

Esqueci de uma coisa:

Limitei meu uso de mouse apenas ao GET atual, num GET de caracteres, por exemplo.
Não permito sair de um GET com o mouse.
Isso é para o usuário não pular validações obrigatórias.

No começo deste post, até achei que poderia ser uma solução para o meu caso, poder liberar o mouse à vontade...
Depois pensei em parte de tudo que pode ter num WHEN ou VALID... melhor deixar como está - time que está ganhando não se mexe.

Agora tente imaginar o mouse fazendo isso, mas executando o WHEN e o VALID.
Dá pra imaginar o que pode ter num WHEN ou num VALID que não cause problemas?
Pode até ter algo pra pular direto de um campo para o outro.
E a mudança do mouse travar tudo, ou entrar num loop infinito.

A título de curiosidade:
Esse foi um grande problema no VB5, e ainda pode ser problema de muito programador.
No Textbox, que seria o equivalente do GET, tinha as rotinas de GotFocus(), LostFocus(), SetFocus()
Seriam as equivalentes do WHEN e do VALID, e mais a que posiciona diretamente em um campo.

Então na rotina tinha um SetFocus pra posicionar num "get".
Só que a LostFocus (VALID) não deixava sair do get anterior.
Ou a GotFocus (WHEN) não deixava entrar no próximo get, ou dependia de algo.
Resultado: tudo travado. O programa não conseguia mais nem ir nem voltar.
Como isso foi resolvido no VB6, versão seguinte: inventaram uma nova rotina Validate(), executada antes do LostFocus().

Navegação entre campos é um negócio perigoso de se mexer.
É daquele tipo de coisa que a gente pensa que pode resolver um problema, e depois cria um problema ainda maior.

Na época que limitei o uso de mouse, só pensei nas validações, ou de um campo depender de outro.
Só mantive na Getsys a rotina acima pra caso um dia mudasse de idéia.
tinha até esquecido disso.
Agora vi que me livrei de um problemão.

Está aí uma solução definitiva: limitar o mouse ao GET atual.

[Eolo]

gente boa tarde!
Não sabia que uma simples resposta minha, gerou este alto nível de professores se dissertando entre si... fiquei 2 dias ser ver o post e deu 3 páginas de discussão.
vlw ReadExit(.t.) setas pra cima/baixo

de Paula,

O Jairo já lhe corrigiu, mas talvez você não tenha notado. Veja:

Setando ReadExit( .f. ), impede APENAS a saída do READ com as setas respectivamente quando estiver no primeiro ou último Get. Não inibe as demais teclas, somente as setas.

Vale, então, clarear.

As setas acima e abaixo mudam o foco pro GET anterior ou posterior, respectivamente, SEM depender do estado do ReadExit().

O ReadExit(), que quer dizer “SairdoRead” e cujo default é .T. (ou seja, SIM), só interfere nas setas acima ou abaixo e, ainda, só quando o foco está no primeiro ou último GET:

- quando o foco está no primeiro GET e você tecla seta acima, estando ReadExit(.T.), o Read é encerrado.

- quando o foco está no primeiro GET e você tecla seta acima, estando ReadExit(.F.), o Read não é encerrado.

- quando o foco está no último GET e você tecla seta abaixo, estando ReadExit(.T.), o Read é encerrado.

- quando o foco está no último GET e você tecla seta abaixo, estando ReadExit(.F.), o Read não é encerrado.

Então, se você não está nem no primeiro nem no último GET, as setas acima e abaixo mudam o foco pro GET anterior e posterior, independentemente se ReadExit() está .T. ou .F.

[asimoes]

Em aplicações como por exemplo delphi, normalmente as validações são feitas no botão Salvar ou coisa do tipo.
Com harbour poderia até ser assim em aplicações com get..read na saída do read, não sei se compensa.

Agente ver isso até em páginas da web, depois que você achou que preencheu todos os campos obrigatórios, os campos validados mudam de cor.

Sei lá, tudo é uma questão de gosto.