PC Toledo

Está certo Jairo ! Em boa hora. Obrigado pela sua observação.

Neste enunciado, o que importa é saber se o conteúdo de tais variáveis, possuem dados, isto é, foram atribuídas ou pre-definidas através do processo de ler de um arquivo .MEM

A minha colocação dá lugar a uma formação equivocada de conceito sobre TYPE e VALTYPE.

Valeu Jairo !

Pablo,

Veja que já fiz o que você sugeriu na última mensagem, até coloquei um Try com um comando Wait a cada linha, para saber em qual linha o sistema para.

Uma vez executado o comando Restore, é mostrado a mensagem de erro já informado acima "Restore failed", numa janela tipo windows com um único botão.

Quanto a verificação das variáveis restauradas, já faço logo em seguida ao Restore, só não tinha informado isso antes.

Parece que o Restore é diferente para a versão do xHarbour que eu uso (1.0)

Segue em anexo o arquivo .MEM quebrado.

Agradeço a atenção de todos e acredito que tudo que postamos aqui serve para melhorar a compreensão de todos nós amantes das linguagens xBase.

Clodoaldo, qual é a estrutura do arquivo que você anexou ?

Por acaso são estas as variáveis no arquivo mem ? Clodoaldo, é extramente enorme. Quase 120 variaveis. Você não acha que ocupar tanta memória com tantas variáveis isso poderia comprometer com o garbage collect, saturação de memória, swap...

Na minha opinião, a maioria dessas variáveis refere-se a comandos de impressora padrão Epson então poderia ler-las através de um DBF e não ocupar memória.
Outras eu gravaria em arquivo INI.

Eu tentei carregar esse arquivo mem (renomeado claro) e compilado em Harbour, mas não deu erro algum mas também não reconheceu variavel alguma...

Olá gente...
Este arquivo (SFP_VIRTUALCLODO.txt) não é nem parecido (verificado com um Hex-Editor) com qualquer arquivo .MEM que eu utilizava com o 'velho' Clipper (início dos anos 90).
Talvez seja por aí...
T+, Euclides

Euclides escreveu:Este arquivo (SFP_VIRTUALCLODO.txt) não é nem parecido

Pois é... eu também achei que perdeu o padrão, mas consegui ler-lo também. Tal é assim que expus os nomes das variaveis.

Olá Pessoal,

É que o xHarbour e Harbour leem normalmente um arquivo .MEM criado pelo Clipper, porém, ao salvá-lo ele será salva no formato [x]Harbour perdendo a similaridade com Clipper, principalmente porque em [x]Harbour ele salva as variáveis com nomes longos, não limitados a 10 caracteres como o Clipper.

Jairo Maia escreveu:...porém, ao salvá-lo ele será salva no formato [x]Harbour perdendo a similaridade com Clipper, principalmente porque em [x]Harbour ele salva as variáveis com nomes longos, não limitados a 10 caracteres como o Clipper.

Nossa ! Tou de cara com isso ! Isso deveria ser tratado de forma opcional...

O Harbour também faz isso ?

Olá Pablo,

Pablo César escreveu:O Harbour também faz isso ?

Sim. Quando usamos [x]Harbour, significa tanto xHarbour como Harbour. Ambos têm o mesmo comportamento com os arquivos .MEM do Clipper, que em [x]Harbour a extensão se omitida passou a ser .HBV

Interessante, obrigado Jairo pelo esclarecimento.

Mas o estranho que o Harbour tentou ler e não mensagem algum de erro. Mas também não disponibilizo as variáveis contidas nele...
Refiro-me a este caso do Clodoaldo.

Parece que houve alguma modificação recente (bem fresh) a respeito ou estou enganado:

2015-02-21 15:33 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* ChangeLog.txt
* src/compiler/hbmain.c
* src/nortl/nortl.c
! save and restore SETs which can be modified by -fn[:[l|u]|-],
-fd[:[l|u]|-], -fp[:<char>] and -fs[-] compiler flags.
It fixes problem with HBMK2 so now above switches can be used
with HBMK2.

2015-02-21 14:34 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* src/rdd/delim1.c
* src/rdd/sdf1.c
! disabled code which allows to delete just added record.
It was not Cl*pper compatible and caused bad side effects
in COPY TO ... DELIM | SDF - deleted records were nor
copied

Pablo César escreveu:Mas o estranho que o Harbour tentou ler e não mensagem algum de erro. Mas também não disponibilizo as variáveis contidas nele...

Sim. Há diferença entre as funções de leitura entre xHarbour e Harbour nesse quesito. Tanto em Clipper como em xHarbour se o arquivo não puder sido se tem um RTE (Run Time Error), já em Harbour, não se tem o RTE, porém, as variáveis não serão lidas.

Você pode por exemplo tentar restaurar em Harbour variáveis de um arquivo .TXT (ou qualquer outro) que não dá erro, e obviamente nenhuma variável é carregada. Em Harbour é possível checar se as variávei foram carregadas como coloquei neste exemplo.

Editado:

Pablo César escreveu:Parece que houve alguma modificação recente (bem fresh) a respeito ou estou enganado

Pablo, isso não se refere as funções de Salvar/Restaurar variáveis de memória, mas sim em relação aos SET´s para o compilador. É de Hoje, nem sei como funciona.

Jairo você sempre tão atencioso...

Eu devia ter mencionado a minha re-edição (só por respeito).

Acho que aquelas opções de HBMK2 refere-se a converter (l=lower u=upper) todos os nomes na tabela de referência na compilação. Creio que isto aplica-se mais no ambiente em linux.

Olha o que achei no changelog a respeito de arquivos .mem:

2010-05-17 20:47 UTC+0200 Viktor Szakats (vszakats.net/harbour)
* include/hbextern.ch
* src/rtl/Makefile
+ src/rtl/memvarhb.prg
+ Added:
HB_MVSAVE( <cFileName>, [<cMask>], [<lIncludeMask>] )
HB_MVRESTORE( <cFileName>, [<lAdditive>], [<cMask>], [<lIncludeMask>] )

They serve the same purpose with same interface
and similar behavior to __MVSAVE()/__MVRESTORE()
(and __MSAVE()/__MRESTORE(), and 'SAVE TO' command),
only that they support longer than 10 char variable names.
It is not possible to add such support in Clipper-style
.mem files, so these functions will create an incompatible
file format with default '.hbv' extension.

; TOFIX: __MVRESTORE() restores variables as PRIVATEs
while HB_MVRESTORE() as PUBLIC. [DONE]
; NOTE: GETLIST exclusion is solved with simple trick,
as I couldn't find how it's solved in __MVSAVE(). [SOLVED]
; Consider this experimental solution to the problem. [FINALIZED]

Aqui neste changelog Viktor menciona como optar pela forma antiga em Clipper. Então retiro o que eu disse.

19991116-15:05 GMT+1 Viktor Szakats (vszakats.net/harbour)
* source/rtl/memvars.c
! __MSAVE() Modified to save MEMVARs with names longer than 10 chars, the
this way it's more Clipper compatible. But since only the first 10 chars
of the name can be stored in the .MEM file, the complete name cannot
be retrieved on RESTORE. One more issue: if you have multiple long name
which have the same first 10 chars, all these variables will be saved to
the .MEM file, with the same name.
So to be 100% Clipper compatible you should compile Harbour with
-DHB_SYMBOL_NAME_LEN=10.

Amigos,

Antes de mais nada, para compilar meus sistemas uso o seguinte:

xHarbour version...: xHarbour build 1.0.0 Intl. (SimpLex)
xHarbour built on..: Nov 8 2007 09:23:44
C/C++ compiler.....: Borland C++ 5.5.1
Multi Threading....: NO
VM Optimization....: 0

IDE: xDev Studio 0.70

Libs: What32, hbZip, LibPdf, GTwvw, DbfCdx e outras que o xDev Studio traz no seu script automaticamente.

Pablo:
Realmente essas variáveis se tornam públicas, são muitas e ficam ativas no sistema o tempo todo, sendo que, cada uma serve para alguma coisa na framework do GAS-Pro, mas acho que elas nunca me trouxeram algum problema referente a memória.

Na verdade tinha preocupação com memória, bem antes com o velho Clipper, mas ainda assim vou seguir sua dica e desativar algumas que acho que não uso mais.

Como você usa o Harbou para compilar seus fontes, este deve ter um tratamento diferente do xHarbour.

Outra coisa, Salvar e restaurar variáveis em arquivo .MEM é muito rápido e prático, acho que é uma das vantagens do velho Clipper que as outras linguagens deveriam copiar, hehe.

Euclides:
Pode acreditar que o arquivo que enviei foi criado com o xHarbour que mencionei acima e apaguei uma variável do início deliberadamente para que vocês vissem o erro.

Professor Jairo:
O meu primeiro problema com o .MEM no xHarbour (versão citada acima), é que ele só salvava as variáveis com 10 caracteres, pelo menos com o comando "Save To arquivo All Like var*".

Pergunto então para o amigo se tem uma outra maneira de salvar variáveis dinâmicas no xHarbour 1.0.0, ou até mesmo uma função tipo as "HB_MVSAVE() e HB_MVRESTORE()".

A todos:
Percebi que a mensagem de erro que é gerado pelo xHarbour é diferente de quando, por exemplo, quando temos uma variável inexistente no decorrer do sistema, que é gerado até um arquivo error.log.

E eu só não mudei ainda para o Harbou (versão mais nova), por que não encontrei a GTwvw e a viabilidade de gerar relatórios PDF tão facilmente quanto no xHarbour 1.0.0, pois tenho mais de 300 relatórios no meus sistemas, que levariam muito tempo para convertê-los para outra solução.

Eu entendo que um programador deve conceber um aplicativo de maneira a facilitar a vida dos operadores, por isso sou muito preocupado em tratar todas as mensagens de erros geradas pelo sistema e ainda envia-las para meu datacenter. Dou a possibilidade de gerar relatórios em todas as partes, consultas, nos edites e uma vasta relação de relatórios pré-definidos, com possibilidade de serem gerados em formato Paisagem ou Retrato também. Com isso diminuo muito o tempo de suporte a meus clientes, trazendo assim um ganho real de tempo par minha empresa.

Finalmente, acho que um recurso tão poderoso quanto esse não deveria ser esquecido ou negligenciado pelo pessoal que controla a "produção" do [x]Harbour e caso queiram meus fontes completos de um dos meus sistemas, lhes enviarei de imediato.

Agradeço a todos pela atenção.

por que não encontrei a GTwvw e a viabilidade de gerar relatórios PDF

A pessoa que consertou a GTWVW (reescreveu toda) foi o Viktor.
No Harbour 3.2 ou 3.4 (fork do Viktor) ela funciona bem.
Quanto ao uso do PDF; Como você usa ?
Até com o xHarbour mais atualizado do SVN, acredito que terá sucesso em usar a GTWVW, e resolvido seu problema com arquivo .mem

...não deveria ser esquecido ou negligenciado pelo pessoal que controla a "produção" do [x]Harbour

E não foi. Foi melhorado.

Ps. Única ressalva pode ser com o xDev, porque algumas libs mudaram o nome.

Saudações,
Itamar M. Lins Jr.

Olá Clodoaldo,

clodoaldomonteiro escreveu:O meu primeiro problema com o .MEM no xHarbour (versão citada acima), é que ele só salvava as variáveis com 10 caracteres, pelo menos com o comando "Save To arquivo All Like var*".

Acho que aqui você inverteu. O problema era que o xHarbour lia normalmente o arquivo gerado pelo Clipper, e com o limite de 10 caracteres no nome da variável. Então, como ocorreu nos relatórios gravados em Clipper em sistemas gerados pelo GasPro, lia a variavel com 10 caracteres, e nos fontes a variável tinha mais de 10. Como xHarbour usa mais de 10, dava o conflito.

Por exemplo: Em Clipper: MinhaVariavel era salva como MinhaVaria (truncada em 10 caracteres). Então depois de restaurar em xHarbour o arquivo .Mem gravado pelo Clipper e tentasse algo tipo: MinhaNovaVar:=MinhaVariavel, se tinha o erro de variável não existe: MinhaVariavel.

clodoaldomonteiro escreveu:tem uma outra maneira de salvar variáveis dinâmicas no xHarbour 1.0.0, ou até mesmo uma função tipo as "HB_MVSAVE() e HB_MVRESTORE()".

Não conheço Clodoaldo. Talvez você pudesse tentar compilar em seu programa as funções em C da Hb_MVSave() e da Hb_MVRestore(), mas nunca tentei.

Olá Pablo,

Pablo César escreveu:So to be 100% Clipper compatible you should compile Harbour with -DHB_SYMBOL_NAME_LEN=10.

Legal esse recurso Pablo, mas veja que não só as variáveis dos arquivos .Mem são afetadas, mas sim todoas as variáveis do sistema. Mas foi um recurso que eu não conhecia mas deixava o [x]Harbour 100% compatível com Clipper em termos de variáveis.