Olá,
Como eu disse anteriormente, o problema não está na macro, mas no fato de ser estática. Se você chama uma função estática no valid, pode funcionar, mas se chama ela com macro, não deveria mesmo funcionar. Em tese, o Eval() não teria como ler um símbolo estático 'compilado em tempo de execução', como se diz dos codeblocks.
Toda macro que envolve nome de função, será executada via Eval(), como bloco de código, não há como fugir disso.
Variáveis (e funções) dentro de blocos de código são tratadas como locais, e só podem vir a ser enxergadas fora do bloco se tiverem sido declaradas como públicas (funções são públicas por padrão).
Quando você executa algo do tipo:
{ |a,b,c| funcao( a, b, c ) }
As variaveis a, b e c não são visíveis dentro do seu programa, pois elas são locais dentro do bloco, como se fossem parâmetros.
Não sei se fui claro, mas o mesmo acontece com funções. O conceito é o mesmo.
De resto, no xHarbour funciona porque eles descaracterizam as funcionalidades originais do Clipper. Exatamente por isso chegou-se a um beco sem saída.
Leia isso (wikipedia):
http://pt.wikipedia.org/wiki/Harbour
xHarbour é uma bifurcação[6] no desenvolvimento do Harbour. xHarbour sempre tomou uma posição mais agressiva na adoação de novas tecnologias, enquanto o Harbour preferiu se concentrar na compatibilidade com o Clipper em um primeiro momento para depois implementar novas funcionalidades. Harbour também se concentrou em suportar uma grande variedade de sistemas operacionais enquanto o xHarbour suporta basicamente o MS Windows e o Linux 32-bit.
Os desenvolvedores do Harbour tentam documentar todos os comportamentos que não são oficialmente documentos pelo Clipper e testar todo código compatível com Clipper para compilar com o Harbour mantendo sua compatibilidade total, incluindo os bugs não críticos do Clipper.
Os desenvolvedores do Harbour rejeitam mudanças que quebram a compatibilidade com o Clipper, embora essas rejeições estão sendo revistas agora que o Harbour tem uma arquitetura muito bem implementada e permite extensões à linguagem sem alterar o núcleo do compilador.
Em 2010 Harbour teve um ganho considerável na sua adoação após o lançamento da versão 2.0 que provou ser muito estável, poderosa, flexível e moderna, enquanto o xHarbour tem sido negligênciado pelos seus desenvolvedores e vem perdendo apoio por parte dos seus usuários, como pode ser verificadas em suas listas [7] [8] [9].
Recentemente um texto chamado xhb-diff.txt[10] disponível na distribuição do Harbour demonstra as inúmeras deficiências do xHarbour em termos de arquitetura que praticamente impossibilitarão a adoção de forma consistente de futuras modernizações na linguagem sem causar mais compromissos do que já carrega.
