Atribuir um mesmo valor ao get em fontes distintos

[Gelson]

?la, amigos do forum !

Tenho uma rotina que faz a inclus?o nas contas cadastradas no sistema e fiz uma outra rotina que verifica se o saldo da conta est? estourado, uma vez que cada conta possue um campo limite com um valor qualquer. O problema ? que analisando a quest?o o mais adequado seria a cada confirma??o de lan?amento o sistema mostrar se a conta estourou, e mediante a tecla acionada pelo usu?rio continuar os lan?amentos.

Neste caso precisaria que meu fonte ccop14 ( que verifica o estouro de limite ) assumisse automaticamente em get mconta o mesmo valor da conta digitada no fonte de inclus?o o ccop10 e que depois de exibida a mensagem de estouro de limite voltasse na tela de inclus?o de lan?amento.

Tentei chamar usando DO CCOP14 ap?s a linha de confirma??o dos lan?amentos no PRG de inclus?o, at? funciona por?m o usu?rio tem de sair da tela de inclus?o, e digitar a conta novamente por causa do GET do fonte que verifica o estouro de limite.

Os fontes separadamente funcionam perfeitamente como posso fazer este procedimento funcionar ?

[Pablo César]

Caro Gelson,

Não sei ainda se alguém ja respondeu esta sua questão. Pois percebí que tem este mesmo assunto mais de 4 vezes. Confesso que está meio confuso o sua colocação do seu problema. Mas acho que algo entendí.

Você menciona de uma rotina chamada CCOP14, esta rotina é apenas o nome de um PRG ou é uma função ?. Se for uma função, beleza !. Senão, coloque no inicio desse PRG, um nome de função que lhe convier (digamos SHOWSALDO() ) mas lembre que você deverá compilar esse CCOP14.PRG na marra (forçando a compilação) e mudar a chamada CCOP14 para SHOWSALDO() em todos os PRGs que você está chamando o CCOP14. Ok ? Entendeu ?.

Bem depois de estabelecido essa questão. E diria para você:

"Bem vindo ao Clipper 5.0" ! ou de versão mais atual... hehe (desculpe a brincadeira!) e que me parece que o seu CCOP14 é um PRG mesmo, e esse tipo de programação (estrutura dos seus PROCEDURES ou funções e módulos) são da versão mais antiga do Clipper.

Daí em mais, vai ficar muito simples de resolver. pois ainda tem um exigência no final do seu CCOP14, tem que retornar o valor de saldo. Até seria melhor que você postasse o seu código fonte do CCOP14.PRG assim dou uma forcinha para ver se necessita algo mais para transformar esse módulo em função.

Exemplificando um pouco do que você vai precisar:

Código: Selecionar todos

VCLI:=1
VAR1:=0.00
VLIMITE:=3000.00
@ 12,00 say "Valor" GET VAR1 PICT "@E 9,999.99" VALID SHOWSALDO(VAR1,VCLI)<=VLIMITE
READ

FUNCTION SHOWSALDO(VVAL,VCLI) // Esta função ficaria dentro do CCOP14.PRG
VQSEL:=SELECT()
SELE 1
SUM ALL SALDO TO VSAL FOR CLIENTE=VCLI
SELECT(VQSEL)
IF (VSAL+VVAL)>VLIMITE
   ALERT("Limite excedido ! Digite outro valor menor...")
ENDIF
RETURN (VSAL+VVAL) // Isto fará que retorne com o valor do saldo mais o valor digitado

Acho que a modo prático é isso que você precisa. Não esqueça de postar seu módulo CCOP14.PRG

[Maligno]

precisaria que meu fonte ccop14 ( que verifica o estouro de limite ) assumisse automaticamente em get mconta o mesmo...

Primeiro de tudo: se puder, esqueça as procedures. Elas são ineficientes diante das funções. Há muito tempo as procedures não são mais recomendadas.
Segundo: uma função que calcula não deve comparar. Uma função que obtém uma entrada não deve pesquisar. Uma função que pesquisa não deve exibir diálogo informando que não encontrou. E assim por diante.
O que eu quero dizer é que ao incorporar tarefas diferentes numa só função você fatalmente acaba criando problemas no futuro. Perde-se modularidade e os "componentes" ficam difíceis de "encaixar. Parece ser bem este o seu caso.

A receita da solução, conforme consigo ver seu problema, me parece bem simples: na saída do GET que obtém o valor do lançamento você executa uma função que compara o valor digitado com o valor limite da conta. Use VALID para isso, que facilita o trabalho. Na função de teste você chama outra função que lhe dá o valor limite. A função que passa o valor limite executa a pesquisa no banco de dados. Esta última função pode ser quebrada mais ainda, se quiser.

É mais ou menos como o Pablo indicou, embora eu fizesse diferente. Pesquisa do valor limite do saldo é algo que pode ser necessário em várias situações. Merece uma função só pra ela. Eu faria algo +/- assim:

Código: Selecionar todos

@ GET cConta pic ... 
@ GET nValor pic ... VALID CheckLim()
READ

// Esta função é própria para uso neste GET e não deveria
// ser visível fora dele. Logo, deve ser estática.
static function CheckLim()
local nLim
if GetLimCta(cConta,@nLim) // valor por ref.
   if nValor > nLim
      // Erro
      // Mostre o aviso de erro que quiser
      return .f.
   end
else
   // A conta não foi encontrada
   return .f.
end
return .t.

// Esta função, como é genérica, faz parte da biblioteca do
// projeto e não do GET. Ela serve para todo o seu projeto.
// Por isso, o ideal é que seja mantida à parte. Note que a
// função executa uma única tarefa. Mas ainda pode ser mais
// dividida, caso queira.
function GetLimCta(cCta,nLim)
local lRet := .f.
if PROCURA_PELA_CONTA_INFORMADA
   // Achou a conta
   nLim := VALOR_LIMITE
   lRet := .t.
end
return lRet

Espero ter consigo passar a idéia de quão importante é a característica da unicidade das funções. Misturá-las nunca é um bom negócio. Aliás, um exemplo recorrente, que de vez em quando aparece no fórum: validação de CNPJ. De vez em quando aparece e em 99% dos casos, a função tem um ALERT qualquer para avisar quando o CNPJ é inválido. Nada mais errado. O que calcula não deve mostrar nada.

Se você acha que o problema que o aflige não tem raiz na teoria da unicidade das funções ou deseja ignorar esse assunto, buscando solução por outros meios, me desculpe pela longa mensagem. Mas certamente ela servirá para outros colegas que passam pelo tipo de problema que comentei.