PC Toledo

Tem que debugar na lib também você deve ter os fontes.

prmuller escreveu:e na função PARSE(xArg1,xArg2), na linha 1338 do Gas4harbour.prg ele vai varrendo a função e retorna à mesma linha e daí não sai mais

No Debug mostra qual é o conteúdo dos parâmetros xArg1 e xArg2?

Lembrando que nesta função PARSE() o primeiro parâmetro tem que ser passado por referência, por exemplo: PARSE(@TEXTO,"|")

Abraços,

Paulo,

Ainda bem que temos o debug, já resolvi muitos problemas assim.

Uma dica vai movendo a função altd() até o ponto antes do erro, ai você parar a execução do programa e ver as variáveis e áreas de trabalho abertas no ponto da
parada.

Boa diversão!

Paulo, apenas lembrando que para o debug funcionar corretamente após você ter inserido o parametro -b no arquivo hbp, precisa fazer uma compilação incondicional usando o parâmetro -rebuild.

Amigos, Toledo, Jairo, Alexadre, etc,

Sabem qual é o gostoso de tudo? A vontade de descobrir.
Não existe um problema, no cliente tudo anda normalmente. O cerne da questão esta na linha 348 da mov_ptr (erro de sintaxe).
Mas, por quê, apenas em alguns dbfs? O Gaspro é padronizado quando gera seus fontes, pela lógica, se um esta certo, os outros também estão.
Como hábito de programador e, creio, vcs, são bastante experientes, eu nunca fiz qualquer modificação sem antes fazer uma cópia e manter um rigoroso diário de bordo, anotando data, modificação, etc.
Esse erro 1449 é recorrente. Não sei quantos de vcs ainda usam o Gaspro (O Jairo tenho certeza, rsss), e, ele aparece e, às vêzes some, e ninguèm colocou o pq disso.
No nosso caso, é certo que esta na mov_ptr, no retorno da variável chv_. Dá o 1449, erro de sintaxe.
Bem, o Jairo pediu para que eu obtivesse o retorno, mas, no dbf em questao era impossível, pois ali estava erro.
Obtive o retorno de outros dbfs que estavam ok e, a resposta é o índice da consulta, numa cadeia de caracteres.
Uma solução emergencial seria, apelar, como IF ALIAS() == Mo_CAXA, etc.
A funcão, após isso usa EVAL para avaliar, então,, no IF acima formaríamos um codeblock para forçar o índice primário do Mo_caica (nr_lacam).
Não testei, mas aposto que vai funcionar, e assim seria com outros que dessem esse erro, ELSEIF, etc.
Seria aquela que todos nós já fizemos a ^gambiarra^ definitiva (bons tempos).
Tenho certeza de que, todos, que converteram, a pariir do Gaspro, seguindo as orientações do Toledo já passaram ou, estão passando por isso, também, e, acho, que, , juntos, vamos descobrir a origem. Esse bendito erro vem desde o tempo do Gaspro no clipper e o Silvano (da Gas Informática, nunca deu a solução).
Curiosidade, para quem não sabe, o GasDos foi escrito em linguagem?????? C

Nunca usei a gaspro, sei que é uma mão na roda mas eu prefiro codificar na unha os meus códigos, assim eu sei perfeitamente o que acontece.

Alexandre,
Nem precisa, o Gas gera rotinas idênticas para qualquer prg. Economiza um tempo enorme, e vc somente acrescenta as suas, quando necessárias. Muito fácil e intuitivo o uso. Não sei se é o caso, mas, ele hoje já é free, embora difícil de achar na net. Se quizer testar, mante o e-mail que te passo com prazer.

Oi Jairo,

Me esqueci de te passar a dica, que, peguei aqui mesmo no fórum, creio que o Jose Quintas.
Não necessariamente presisa usar o -rebuild, se quizer, pode usar -inc. Para isso, basta que, antes de usar o hbmk2, vc use del WorkDir/seumodulo*.*
Já testei, e, funciona legal!

Sds,
Paulo Muller

Paulo,

O gaspro tem na seção de download, nas minhas compilações eu deixo o -rebuild habilitado assim eu garanto que todas as funções vão ser testadas pelo harbour.

Olá Paulo,

prmuller escreveu:Não sei quantos de vcs ainda usam o Gaspro (O Jairo tenho certeza, rsss)

Usei muito o GASPro, hoje não mais. Uso Harbour + WVG.

prmuller escreveu:Uma solução emergencial seria, apelar, como IF ALIAS() == Mo_CAXA, etc.

A rigor, no seu caso quem está chamando a Mov_Ptr() é a função LDBEdit(). Como você diz que não tem consulta gravada para este DBF e nem os DBFs relacionados, fica difícil entender, uma vez que na LDBEdit() naquele trecho só passa quando existe consulta gravada. Basta analisar a função LDBEdit().

Porém, uma forma de você evitar este erro é fazer uma alteração na função Mov_Ptr(), e bem no início. Logo após a linha das variáveis locais, coloque isto: Isso evitará o erro quando não houver indice aberto. Teste isso e veja se a consulta principal será aberta normalmente.

prmuller escreveu:Não necessariamente presisa usar o -rebuild, se quizer, pode usar -inc. Para isso, basta que, antes de usar o hbmk2, vc use del WorkDir/seumodulo*.*

Quem sou eu para dizer algo sobre uma dica do mestre José Quintas, mas será que você entendeu a dica dele? Penso que pode estar havendo confusão ai.

O parâmetro -inc indica ao compilar para compilar apenas os arquivo alterados, o que almenta e muito a velocidade de compilação. O parâmetro -rebuild, é usado quando desejamos que todos os arquivos sejam recompilados independente de terem ou não sido modificados.

Usar -rebuild é o mesmo que remover do seu arquivo .hbp o parâmetro -inc. Se ele parâmetro não for colocado ou estiver comentado, a cada compilação todos arquivos são compilados normalmente.

Oi Jairo, bom dia!

Entendi sim, o -inc trabalha apenas o que foi modificado com ganho de tempo na compilação e o -rebuild gera tudo outra vez (equivalente a se apagar os objs no clipper), daí ele ter orientado a, se for usar o debug num módulo específico, apagar os arquivos pertinentes no workdir.
No caso do arquivo de caixa, o debug já havia mostrado (F6) área não indexada. Fiz como vc orientou e não deu erro mais, porém, só mostrou um registro de 2007. Esse dbf tem sim consultas gravadas (16) e elas funcionam normalmente. Eu acho que, o caminho é esse, passando pela LDBEdit(). Como hoje é sábado e o meu tricolor só joga às 17 h, vamos testando. De qualquer forma, obrigado. Agora vou ver o porquê de um só registro.

Sds,
Paulo Muller

Paulo, por favor:
1-Poste a imagem do menu das consultas. Este que aparece as consultas gravadas e a opção: Definir nova consulta.
2-Se você alterou a função LDBEdit() em algum momento (ou se não tem certeza disso), poste também essa função. Se ela é original do GASPro, não é necessário.

Afinal pra que a pressa de ver o tricolor levar um pacote a partir das 17h00m? -:]

Jairo,

É aí que esta o problema, vc nem entra na consulta principal para mostrar o menu que vc pediu.
Vou substituir a Edita() por uma consulta extra para aparecer e depois posto.
A função LdbEdit() é nativa do próprio gas.

Sds,
Paulo Muller

Jairo, bom dia!

Estou postando o menu solicitado.
Fiz alguns testes, com os fontes em outro diretório, voltando ao início. Recompilei no clipper 5.3 com o exospace e refiz o processo de conversão. A princípio, tudo voltou ao normal, menos o arquivo de fornecedores (aquele do campo cpf com tamanho e máscara incompatíveis).
Como tenho bastante modificações pessoais no arquivo Sag_func.prg vou agora seguir meu diário de bordo efetuando, passo a passo, as alterações feitas para tentar descobrir em que ponto apareceu o erro.
Já que no cliente tudo esta legal, não existe pressão e creio que alguma coisa vai aparecer.
Por enquanto, meus agradecimentos a você e ao Alexandre pela ajuda.

Sds,
Paulo Muller

Jairo, boa tarde!

Estou postando a imagem com o retorno da variável chv_ na função mov_ptr obtida em arquivos sem problemas e sempre, com o mesmo retorno.
Conforme previsto, estou refazendo todos os processos e até agora tudo nomal.
Voltando ao diretório onde ocorre o erro 1449, a LDBEdit(), linha 2704, faz uma chamada _a mov_ptr onde gera esse erro 1449 (erro de sintaxe) na variável chv_. Esse retorno da chv_ é codeblock que é avaliado, mais abaixo, na mov_ptr pela função Eval(). Não consegui ainda entender esse retorno, já que, analisando o código não me parece ser o que deveria retornar.
Vamos tentando, pois, uma hora aparece a causa.

Abraços,

Paulo Muller