PC Toledo

Muitas vezes vemos aqui colegas "penando" para descobrir o que estão fazendo de errado, porque determinado cálculo não chega ao esperado, como o programa está se comportando, por onde passam as rotinas, dentro das
diversas opções motivadas pelos,

IF
..
ENDIF

FOR
...
NEXT

DO WHILE
...
ENDDO


Sendo assim, bolei uma estrutura super simples, usando apenas a função AADD do Clipper, criando uma matriz com todos os valores assumidos pelas variaveis do sistema, inclusive com os os nomes das PROCEDURES e FUNCTIONS, com as linhas onde estão sendo executadas as operações. Este processo é bem melhor do que compilar com /B e usar a LIB CLD, não segura em nada o processamento em programas pesados e é fácil de implementar
e depois desativar.

Pode-se por qualquer tipo de variável (alfa, numérica, matriz, etc., desde que devidamente onvertida para string, para ser adicionada ao label que a identifica.

Quando tiver resolvido todos os problemas, basta apenas desativar o bloco final onde está a apresentação por ACHOICE de tudo o que foi obtido no processamento.
Enquando houver dúvida sobre algum processo, inclua outras linhas com o AADD até ter certeza de que descobriu todos os seus erros, pois o computador nunca erra...

Não custa perguntar... mas por acaso conhece o debug do Clipper?
Dá pra acompanhar linha a linha, ver variáveis, áreas abertas, etc.

No Clipper é até melhor que no Harbour, porque todas as opções funcionam.

Uma coisa que usava muito era definir uma determinada condição de pausa, pra acompanhar a partir dali.
Isso é uma das coisas que não funcionava no Harbour, mas não sei se agora funciona.

Tipo parar quando RecNo() == 10, ou quando mVar = 50.

O nosso amigo José Quintas pode não ter percebido que eu citei que eu acho melhor esta minha proposição, em confronto com compilar com /B e com a LIB CLD, que eu acho aplicável a sistemas bem mais simples.
Eu já usei e muito o DEBUG do Clipper, já "penei" na hora de colocar as expressões, ficar alternando entre as tela, ficar dando <CONTROL> D, F5 e F8, e assim por diante.

Quando o sistema se torna muito pesado, como as linhas estão amarradas com a execução, ele fica "meio" amarradão, e você tem de acompanhar em duas telas ( a tela do fonte e a tela das variáveis), alterando-se entre elas, para ver que valores assumiram, e muitas delas são de difícil obtenção ali, pois você tem de colocar a expressão correta depois do "? XXXX := ? , não é ?

Nessa minha proposição, basta incluir na matriz com a função AADD todas as expressões, tais como:

1. campo caracter - NÃO PRECISA FAZER PREPARAR MAIS NADA
ex: AADD(matr_tr,("Campo X ....." + ccampox ))

2. campo numérico simples -> converter para string
ex> AADD(matr_tr,("Soma quantidade vendidas: " + str(nsomavend,6) ))

3. campo numérico valor -> converter para string
ex: AADD(matr_tr,("Soma valor vendas: " + transform(nvalorvend,"@E ###,###.##") ))

4. campo matriz -> converter para string
ex: AADD(matr_tr.("Matriz x,y...: " + str(sede[x][y],5) ))

5. alias de arquivo em uso -> apresentar o alias pela função, ou seja, pode por função dentro a função
ex: AADD(matr_tr,(Arquivo em uso...: " + alias() ))

6. indice aplicado ao arquivo -> converter para string o número do índice atual
ex: AADD(matr_tr,"ìndice do arquivo de cliente...: " + str(indexorder(),2) ))

Ou seja, você executa TODA a rotina e no final você pode ver tudo listado no ACHOICE e apenas com uma verificada em qual procedure/linha/campo ocorreu o erro .
Não importa quantas vezes a rotina passou pelas gravações, está tudo registrado.

Dá até para mandar para um arquivo de saída, e, depois detidamente confrontar com os dados reais e acompanhar a evolução de todos os cálculos, gravações de arquivos de movimento, etc.

Realmente, falha minha.
Não li direito a parte do debug.