Como testar a integridade de arquivo .MEM?

[Pablo César]

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 !

[clodoaldomonteiro]

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.

[Pablo César]

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

Por acaso são estas as variáveis no arquivo mem ?

Código: Selecionar todos

DRVVISIVEL
DRVTITTNA
DRVTITTEL
DRVTITPAD
DRVTITMSG
DRVTITHLP
DRVTITGET
DRVTITENF
DRVTITBOX
DRVTEXP
DRVTENF
DRVTEMPO
DRVTELI
DRVTDE8
DRVTCOM
DRVTC20
DRVTAPG
DRVSSTIPO
DRVSSTEMPO
DRVSOM
DRVSMTP
DRVSAUDAC
DRVRATV
DRVRATH
DRVPW
DRVPVDBF
DRVPRN
DRVPORTA
DRVPORT
DRVPEXP
DRVPESQ
DRVPENF
DRVPELI
DRVPDE8
DRVPCOM
DRVPC20
DRVPADRAO
DRVORDEMLI
DRVNTXTVE
DRVNTXTSI
DRVNTXTNJ
DRVNTXTFU
DRVNTXTBV
DRVNTXTBR
DRVNTXTBN
DRVNTXTBM
DRVNTXTBD
DRVNTXTBC
DRVNTXTBA
DRVNTXREG
DRVNTXMNU
DRVNTXFPA
DRVNTXERR
DRVNTXCPA
DRVNTXCNA
DRVNTXCBO
DRVNTXAFA
DRVNTX
DRVNATUREZ
DRVMOUSE
DRVMES
DRVMENUCEN
DRVMARCA
DRVLICENCA
DRVLAND
DRVISOCIO
DRVIRENDIM
DRVIPLANO
DRVINCL
DRVIINSTIT
DRVIESPECI
DRVIDEPOSI
DRVFONTE
DRVEXCL
DRVERR
DRVEMP
DRVEMAILTI
DRVEMAILRE
DRVEMAILDE
DRVDTDIRF
DRVDIREMP
DRVDIR
DRVDBFTVE
DRVDBFTSI
DRVDBFTNJ
DRVDBFTFU
DRVDBFTBV
DRVDBFTBR
DRVDBFTBN
DRVDBFTBM
DRVDBFTBD
DRVDBFTBC
DRVDBFTBA
DRVDBFREG
DRVDBFMNU
DRVDBFFPA
DRVDBFERR
DRVDBFCPA
DRVDBFCNA
DRVDBFCBO
DRVDBFAFA
DRVDBF
DRVCPFRESP
DRVCORTNA
DRVCORTEL
DRVCORPAD
DRVCORMSG
DRVCORHLP
DRVCORGET
DRVCORENF
DRVCORBOX
DRVCONF
DRVCOD
DRVCC
DRVCARA
DRVCAMINHO
DRVBKP
DRVAUTOHEL
DRVANO

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...

[Euclides]

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

[Pablo César]

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.

[Jairo Maia]

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.

[Pablo César]

...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 ?

[Jairo Maia]

Olá Pablo,

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

[Pablo César]

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

[Jairo Maia]

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:

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.

[Pablo César]

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.

[clodoaldomonteiro]

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.

[Itamar M. Lins Jr.]

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.

[Jairo Maia]

Olá Clodoaldo,

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.

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,

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.