Dúvidas com Get e Read

[Bisteca]

Caros amigos. Estou montando um cadastro de contas à pagar e preciso fazer o seguinte:

@ 1,1 say "digite o numero do titulo: " get ntit
@ 2,1 say "digite o código do fornecedor: " get ncdforn
@ 3,1 say "digite o código do centro de custo: " get ncdcent
read

Ai preciso pesquisar no cadastro de fornecedor o código digitado. Se foi encontrado, preencho com o nome. Se não foi encontrado, que voltar no get do fonecedor.
Depois a mesma coisa para o centro de custo.

Só que como o read esta no fim não sei como fazer isso, não quero usar um read para cada get, pois assim não conseguiria voltar nos campos usando as setas.
Alguém poderia me ajudar?
Obrigado

[Eolo]

Crie uma função para rodar com o VALID.
Um exemplo:

Código: Selecionar todos

...@ 2,1 say "digite o código do fornecedor: " get ncdforn valid achanome()
...


function achanome
sele fornec
seek ncdforn
if found()
  @2,20 say cnmforn
  ret .t. // deixa ir p/ próximo get
else
  @2,20 say "Não Localizado!"
  ret .f. // não deixa sair do get NCDFORN
endi

[ABeltrani]

Ou ainda mais enxuto:

Código: Selecionar todos

function achanome
if fornec->(dbseek(ncdforn))
  @2,20 say fornec->cnmforn 
  retu .t. // deixa ir p/ próximo get 
endi
@2,20 say "Não Localizado!" 
retu .f. // não deixa sair do get NCDFORN 

[rochinha]

Amiguinho

"ESCAPOU" mesmo.

Sua função retornará SEMPRE verdadeiro mesmo que não encontre, sendo que a função do VALID seria a de DEIXAR ou NÃO DEIXAR passar para o proximo campo.

Lógico que voce apenas exemplificou, ficando a cargo do colega solicitante fazer o acerto, teste, etc.

Então ficaria desta forma:

Código: Selecionar todos

function achanome 
priv a=.t. 
if fornec->(dbseek(ncdforn)) 
  @2,20 say fornec->cnmforn 
else 
  @2,20 say "Não Localizado!" 
  a=.f. // ******** pequeno acerto ********
endi 
retu a

Assim, se não encontrar, mostra a mensagem e fica dentro do GET.

[Eolo]

Putz, tem razão.
Obrigado pela correção, Rochinha!

[Gilberto M Silva]

Funcinou direitinho!!!!! )

[gvc]

Se o nosso amigo ainda não conseguiu o que queria:

...
@ 1,1 say "digite o numero do titulo: " get ntit valid achanome(ntit, @ncdforn)
@ 2,1 say "digite o código do fornecedor: " get ncdforn when empty(ncdforn)
@ 3,1 say "digite o código do centro de custo: " get ncdcent
read
...


function achanome(q_tit, q_nom)
if fornec->(dbseek(q_tit))
q_nom := fornec->cnmforn
end
return(.T.)

[Pablo César]

Caro Bisteca,

Eu poderia indicar o uso de TBROWSE, mas como logo ví que era um sistema de contas a pagar, no qual o campo nº do titulo (não precisa ser pesquisado, ja que é único) e visto que talvez você ja tenha desenvolvido o módulo de cadastro, então posso ainda indicar o seguinte:

Eu por exemplo, prefiro que o usuário não prencha código de fornecedor sim faça-se no seu lugar uma rotina de AUTO-PRENCHIMENTO. Isto é possível se você possue este dado previamente cadastrado (código e descrição do fornecedor). Para o usuário, será questão de prencher numa variável temporária do tipo caracter, pegar caracter por caracter do que for digitado e fazer um SEEK na descrição do fornecedor. se houver algum registro que satisfaça por "unanimidade" o que for digitado, então você pode assignar a essa variável ncdforn (código de fornecedor) de uma forma que não seja visualizado. Mas terá que obedecer essa questão de unanimidade.

Explicarei abaixo o que eu quero dizer com isto:

1. Você terá que fazer uma função de pesquisa e digitação de um GET feito por concatenação e em looping.
2. Se o usuário digitar apenas um caracter, digamos a letra "S" (faça sempre em maiusculas o armazenamento, assim não há margem de erros).
3. Daí você irá procurar no campo descrição no DBF de fornecedores(claro que tem que estar indexado por este campo, também). Digamos que nesse campo você tenha dois registros que começam com a letra "S" (SHARP e SONY), por exemplo.
4. Você irá utilizar o SEEK e esta função irá se posicionar no primeiro registro, isto é no registro que contém a string "SHARP". Se enconcontrou, você irá dar um SKIP+1 para saber se o próximo registro também começa com a letra "S". Então se ele achar (que neste caso sim vai achar o registro que contém a string "SONY"), então retorne com SKIP-1 fique no looping para aguardar a segunda letra a ser digitada.
5. Se o usuário, digitar o segundo caracter (digamos a letra "O"), então irá verifica com SKIP+1 e verá que não tem outro registro que comece com "SO", que neste caso é o registro que contém a string "SONY" e então retornará com o código desse único registro.

Sei que soa muito dificil de fazer, mas acho que vale a pena investir nisso, pois uma vez feito esta rotina, você a poderá usar em outras situações semelhantes.

Então em sintese, você exibe o fornecedor mas armazena o código dele, dando a sensação de que o seu sistema "adivinha" o que o usuário deseja prencher. Isto tudo, sem a necessidade de decorar códigos.

Outra forma, seria você apresentar um TBROWSE quando pressionando F2 (digamos) e este faça a procura do NOME do fornecedor a medida que for digitando, uma vez localizado é só dar um ENTER encima do fornecedor desejado e este retornará com o código de tal fornecedor.

[Augusto]

Eu por exemplo, prefiro que o usuário não prencha código de fornecedor sim faça-se no seu lugar uma rotina de AUTO-PRENCHIMENTO. Isto é possível se você possue este dado previamente cadastrado (código e descrição do fornecedor). Para o usuário, será questão de prencher numa variável temporária do tipo caracter, pegar caracter por caracter do que for digitado e fazer um SEEK na descrição do fornecedor. se houver algum registro que satisfaça por "unanimidade" o que for digitado, então você pode assignar a essa variável ncdforn (código de fornecedor) de uma forma que não seja visualizado. Mas terá que obedecer essa questão de unanimidade.

Eu não queria me meter nesse tópico... mas diante dessa alternativa do Pablo me vejo obrigado a faze-lo... Prq ??

Pablo... Não vai aqui nenhuma crítica destrutiva entretanto, devo lembrar que, essa sua rotina é totalmente anti-produtiva e grita desaforos (hehe) para todos os principios básicos do processo produtivo de um "data-enter" de qualquer CPD. O processo de digitar um código e, a partir dele buscar a descrição do mesmo no DB é mais velho do que o "pacote da Maizena" e nunca foi desbancado (salvo engano) por qualquer outro processo, nem mesmo pelo código de barras lido a partir de um leitor ótico.
Suponhamos o DB do INSS p.e. ?? Já imaginou quantos "Washingtons da Silva alguma coisa" existe no cadastro?? O operador do sistema ia ficar muito P da vida !! Ia xingar até a 6a. geração do "Pablo" que desenvolveu um sistema que solicita "trocentos" digitos ALFA para localizar um registro ao invés de 4 ou 6 NUMÉRICOS...

Pablo meu amigo forense... Não queira reinventar a roda !!! Deixe ela redonda que já tá de bom tamanho... hehe

[Pablo César]

Imagine o DB do INSS p.e. ?? Já imaginou quantos "Washingtons da Silva alguma coisa" existe no cadastro?? O operador do sistema ia ficar muito P da vida !! Ia xingar até a 6a. geração do "Pablo" que desenvolveu um sistema que solicita "trocentos" digitos ALFA para localizar um registro ao invés de 4 ou 6 NUMÉRICOS...

KAKAKA sim concordo com você nessa questão de tamanho do DB... mas alí você ja está apelando... mas aceito sua observação e veio bem para esclarecer que no banco de dados muito grande não é conveniente este procedimento. Por isso que essas grandes instituições como bancos e órgão de governos, ainda utilizam-se de sistemas modo CONSOLE estilo "a la COBOL" hihihih (agor sou eu que apelo, hohohoho). Mas convenhamos que tratava-se de uma BD não muito grande de cadastro de fornecedores em contas a pagar. Acredito que o cliente do colega, não deva ser um distribuidor de mercadorias a nível nacional (não querendo menosprezar a alguém) e com respeito a sua questão:

Não queira reinventar a roda !!! Deixe ela redonda que já tá de bom tamanho... hehe

Eu não acho isso ! Acho que SEMPRE é válido RE-AVALIAR técnicas e se for possível ELIMINAR as RODAS meu caro colega. Além do mais, as trocas de informações são muito úteis sem isso não existiriam os fóruns, não é mesmo ?.

Por falar em RODAS, os novos modelos de trens na Europa e China ja funcionam SEM as RODAS. São movidos e levados por elotromagnetismo. Assim que essa questão de RODA redonda ou quadrada não é a questão... hehhe (sei que você utilizou para tirar uma casquinha). Você tem razão que um BD muito grande não seria muito conveniente essa técnica, desde que utilizado o XBASE. Porque se fosse outra linguagem, nós não estariamos gastando nossas digitais aqui discutindo.... hehehe

[Augusto]

Eu não acho isso ! Acho que SEMPRE é válido RE-AVALIAR técnicas e se for possível ELIMINAR as RODAS meu caro colega.

Vc dizendo isso me faz lembrar a história daquele japonês que atendia pelo nome de "Manuel" que dizia ter inventado a "roda triangular" e quando questionado pelo patrício do "prá quê" uma vez que já existia a quadrada ele responde: A vantagem da roda triangular sobre a quadrada é que tem menos um solavanco...

[Pablo César]

KAKAKA.... Mas sei que se algum dia, andares de trem naqueles super-velozes tu irás lembrar de mim... hihihihihi

Mas admita: fica muito mais bonito o auto-prenchimento do que um código de fornecedor.... não ?

Deixemos o Bisteca, dar a sua opinião... coitado após tanto blablabla deve ter desistido... hihihih

[Maligno]

Em nenhuma situação eu permito que o cliente use código interno para identificar peças. Até porque meus códigos internos são aleatórios e imensos (mas reduzidos). Não seria nada confortável usá-los.

Como eu só uso (e tenho) cadastro de peças planificadas (opcionalmente usa apenas números - mas pode conter letras - o usuário decide), o usuário pode digitar apenas parte do código, se quiser. Se o sistema ficar na dúvida quanto ao ítem, um pequeno browser apresenta os ítens que correspondem àquela identificação parcial. Aliás, esse esquema também vale para clientes, pedidos, etc.

[Bisteca]

Caraca meus amigos, por isso que eu gosto deste forum, sempre tem soluções pra tudo e o nível de discussão é muito bom.
Ja resolvi os problemas com a primeira dica.
Obrigado a todos.