PC Toledo

Olá amigos!

Estou tentando mostrar um comando SAY e GET na tela, dependendo da informação de um campo anteriormente preenchido. Sei que o comando WHEN que usamos com o GET pode pular um campo se uma informação anterior foi preenchida incorretamente, mas eu queria excluir da tela as informações do SAY e do GET.

Ex:
mcampo1:='1' //Este campo deve conter 1-Legislativo ou 2-Executivo
mcampo2:=0
DO WHILE .t.
@ 01,00 SAY 'Tipo de poder:'
@ 01,16 GET mcampo1 VALI mcampo1 $ '12'
IF mcampo1='1'
@ 02,00 SAY 'Valor da RCL:'
@ 02,16 GET mcampo2 PICT '@E 999,999.99 'VALI mcampo2 > 0
ENDIF
READ
...
...
...
EXIT
ENDDO
... se eu mudar o valor de mcampo1 para '2', ainda assim é mostrado o SAY e o GET
Enquanto o comando WHEN serve somente para pular o campo GET e ainda assim mostra o comando SAY e o GET.

Desde já, agradeço a ajuda.

Não entendi bem...mas pelo o que eu entendi vc eve coloca o READ antes de mcampo1='1'

Abraços
Leonardo Machado

Veja bem. O comando @...SAY não faz absolutamente nada em nível de leitura. Ele apenas e tão somente permite configurar a matriz que será dinamicamente manipulada pelo comando READ. Portanto, alterar a forma de leitura de um campo com base no valor de outro só poderá ser feito de forma dinâmica, pela manipulação direta dessa matriz.

Não há meio de tornar invisível um campo por qualquer método ou propriedade sem alterar boa parte do fonte GETSYS. O que se pode fazer mais facilmente é simular o "sumiço", reconfigurando o campo para que a cor de frente assuma o valor da cor de fundo. Ele some, mas não será feito qualquer rearranjo da lista (posições).

Para modificar a cor do campo alvo, você terá de configurar uma função para o VALID do campo que servirá de parâmetro para a mudança. Essa função deverá modificar a propriedade ColorSpec do campo. Veja o NG do Clipper, na seção dedicada às "Classes".

Qualquer dúvida volte ao assunto.

Leonardo Machado!
O READ interrompe a navegacao aos campos anteriores a ele, por tanto se eu tiver vãrios campos não vou poder navegar entre os campos.

Maligno!
Já vi na documentação do getsys que tem possibilidade de muda-lo, mas eu achei difícil.
O getsys que uso é o do GASPRO, que tem até opção de HINT ou ajuda a cada campo, acho que o jeito vai ser colocar uma função no VALID ou no PICT.

Valeu a ajuda dos amigos.

Uma perguntaa voces,

Nesse caso poderia ser usado alguma propriedade do get? Tipo:
get:buffer,
get:setfocus()
get:picture
get:assign()
get:reader
get:cargo....
não tem um manual que fale a fundo sobre essas propriedades, se tivesse talvez poderíamos produzir mais sobre as propriedades do get.

O que você pode fazer, facilmente, como eu comentei, é alterar a cor do campo, conforme o valor do campo que modifica essa propriedade. Exemplo: um campo X recebe 1 ou 2. Se for 1, o campo Y deve sumir da vista. Pra fazê-lo sumir, o que se pode fazer é tornar sua cor de frente igual a de fundo. Portanto, é necessário um VALID no campo X e um WEN no campo Y. Um exemplo tosco:
É um exemplo simples. Mais precisaria ser feito para causar um efeito "sumiço" mais convincente. Mas é uma partida para o que você precisa. Apenas atente para alguns detalhes: GetList é a matriz que armazenará os objetos de cada campo e cada campo é acessado pelo número seu número de ordem, na mesma ordem em que ele tiver sido declarado.
E outro detalhe: conforme eu disse, o @...SAY apenas configura a matriz GetList (bisbilhote o PPO do fonte e você entenderá o que eu estou dizendo). Quem faz a leitura de verdade é o comando READ, que invoca uma série de funções que manipularão GetList. Portanto, a chamada Teste() imediatamente antes de READ garante uma reconfiguração das cores do campo Y, caso o valor de partida seja 2. Note também que o comando READ incorpora uma clásula SAVE. Ela é necessária por causa do looping. Sem ela, ao término do READ, GetList seria apagada.

Opa,

Uma maneira mais fácil e profissional seria adicionar um novo objeto GET na matriz GETLIST, de acordo com a condição.

Falou...

Pode ser também. Mas a versão pouco profissional que apresentei é apenas um esboço. Se melhorada em alguns pontos, ficará menos indecente. Mas, apesar da sua idéia ser mais profissional, poderia não ser tão mais fácil, já que, ao adicionar ou excluir um campo, poderia ser necessário reconfigurar toda a matriz para ajustar os valores das linhas e/ou colunas.

Maligno escreveu:Pode ser também. Mas a versão pouco profissional que apresentei é apenas um esboço. Se melhorada em alguns pontos, ficará menos indecente. Mas, apesar da sua idéia ser mais profissional, poderia não ser tão mais fácil, já que, ao adicionar ou excluir um campo, poderia ser necessário reconfigurar toda a matriz para ajustar os valores das linhas e/ou colunas.

No caso não seria necessário reconfigurar a matrz por causa das linhas e colunas, visto que essas propriedades são próprias de cada objeto get (me refiro as linhas e colunas na tela).

A reorganização da matriz, seria necessário, pelo fato de mesmo que este último get inserido seja colocado na primeira linha fa tela, o foco dele seria após o último da matriz., ocasionando confusão ao usuário.

Mas poderá de qualquer forma ser inserido no meio da matriz, com algum tratamento na mesma.

Eu faria assim.

Stanis Luksys escreveu:No caso não seria necessário reconfigurar a matrz por causa das linhas e colunas, visto que essas propriedades são próprias de cada objeto get (me refiro as linhas e colunas na tela).

Em alguns casos poderia ficar um buraco na tela, assim como no exemplo pouco profissional que mostrei. Daí a necessidade da reconfiguração.

clodoaldomonteiro escreveu:Sei que o comando WHEN que usamos com o GET pode pular um campo

clodoaldomonteiro escreveu:mas eu queria excluir da tela as informações do SAY e do GET

Opa.

Como eu disse, excluir da tela não seria a lógica mais adequada na situação, mas sim o contrário, criar o objeto quando a condição for satisfeita.

Se você fizer do jeito certo, pode incluir todos os campos e tornar visíveis apenas os que tiverem de ser visíveis. Meu GET (um exemplo simples, claro - mas funcional):
O segundo campo desaparerá completamente (incluindo o SAY) se X assumir um valor diferente de 1. O campo relacionado a Z (incluindo o SAY) subirá uma linha (scroll). Tudo isso sem excluir ou incluir nada. Assim não fica profissional? ))

Pra mim, lógica adequada é aquela que resolve o problema conforme o contexto que se apresenta, resguardadas as limitações de viabilidade, sejam elas relacionadas ao tempo disponível ou mesmo à perícia técnica.

Ou seja: se só tem tu, vai tu mesmo. Portanto, o exemplo simples que passei na mensagem anterior, se devidamente continuado, vai resolver o problema do colega. Isso não basta? Sei lá. Isso é ele quem vai dizer. Mas uma coisa é certa: ficou bem mais simples do que seria se tivesse que excluir e incluir campos.

pode tambe usar code block
cVar := ""
@ 10,10 say "blabla:" get cVar pict "@!" when 'Funcao de mensagem' ;
valid {|| cVar $ '12',;
iif(cVar == "1",('decisao 1',.t. ou .f.),('decisao 2',.t. ou .f.))}
read

Obs: lembrando que para sair do code block tem que ser verdadeiro a decisao