SAVE and RESTORE

Hello All,

Consider this snippet

PRIVATE cSet := "ONE.SET"
PRIVATE cDet := "WAR07-08F881101WAR07-08F881201"

SAVE ALL LIKE cDet TO (cSet)

cDet := ""

RESTORE FROM (cSet) ADDITIVE

? cDet // displays the contents of the variable


However, in my "real-world" program,

PRIVATE cDetails, cSet := "TWO.SET"

...

cDetails := SomeFunc() // a string of characters

SAVE ALL LIKE cDetails TO (cSet)

...

RESTORE FROM (cSet) ADDITIVE

? LEN(cDetails) // results 0

If I go to DOS and TYPE TWO.SET, the results are
:TH:1:CDET ├ E <DATA>

Of course we are looking for a variable named cDetails.

In Clipper 5.2e it worked as expected.

We are using xBuildW, xHarbour build 0.99.70
Running on WinXP, SP2

Does saving and restoring plain vanilla character type
variables to and from .mem files not work in xHb?

Thanks,
-- Robert

Dear
"Robert Campsmith" <drrobert@sturec.com> wrote in message
news:47273d9a$0$1344$834e42db@reader.greatnowhere. com...
> Hello All,
>
> Consider this snippet
>
> PRIVATE cSet := "ONE.SET"
> PRIVATE cDet := "WAR07-08F881101WAR07-08F881201"
>
> SAVE ALL LIKE cDet TO (cSet)
>
> cDet := ""
>
> RESTORE FROM (cSet) ADDITIVE
>
> ? cDet // displays the contents of the variable

I compile this program, and it displays the text value correctly,
and the value stored in "ONE.SET" shows "CDET" and the text value
unaltered (and correct).

I don't have any flags set to keep from uppercasing the variable
names... could some variant of this be causing your problems?

David A. Smith

Robert,

> However, in my "real-world" program,
> ...
> Does saving and restoring plain vanilla character type variables to and
> from .mem files not work in xHb?

Not that we are aware of. Unless you can show us how to replicate I feel
confident this must be an application issue rather than xHarbour issue.

Ron

Ron,

Here is a stand-alone that runs as expected.

FUNCTION Main

SETMODE(25,80)

PRIVATE cSetFile := "ONE.SET"
PRIVATE cDetails := "These are the details..."

SAVE ALL LIKE cDetails TO (cSetFile)

Alert("Just saved "+cDetails+" to "+cSetFile)

cDetails := ''
RELEASE cDetails

Alert("RELEASEd ValType(cDetails) "+ValType(cDetails))
// returns "U"

RESTORE FROM (cSetFile) ADDITIVE

Alert("RESTOREd ValType(cDetails) "+ValType(cDetails))
// returns "C"
Alert("cDetails: "+cDetails)

RETURN( NIL )

In this example, the RELEASEd ValType returns "U" and the
RESTOREd value is correct.

However, this same code in a test stub in my application
does not behave as expected.

****************************************
FUNCTION TEST17()
*
* Purpose: save to .mem
*
PRIVATE cSetFile := "ONE.SET"
PRIVATE cDetails := "These are the details..."

SAVE ALL LIKE cDetails TO (cSetFile)

Alert("Just saved "+cDetails+" to "+cSetFile)

cDetails := ''
RELEASE cDetails

Alert("RELEASEd ValType(cDetails) "+ValType(cDetails))
// returns "C"

RESTORE FROM (cSetFile) ADDITIVE

Alert("RESTOREd ValType(cDetails) "+ValType(cDetails))
// returns "C"
Alert("cDetails: "+cDetails) // returns ""

RETURN( NIL )
*

The RELEASEd ValType returns "C" and the cDetails variable
is empty. The file on disk contains ":TH:1:CDET" as the
variable name. You may click on this link to see the file.
http://www.sturec.com/pickup/00000/one.set

Here is the difference: The little stand alone test program
does not have any declared libraries. My application has
these libraries as part of the build...
Shell32.lib
xhbzipdll.lib
xHBSIP.dll
gdi32.lib
comdlg32.lib
msimg32.lib
Misc.lib
iphlpapi.lib

My guess is that one of these libraries are stepping on
something and causing released variables to still be
declared as ValType "C" and maybe the same or something else
is corrupting my SAVE ALL LIKE

My environment:
Operating System.: Windows XP Professional 5.01.2600 Service
Pack 2
Available Memory.: 1423696
Multi Threading..: Yes
VM Optimization..: 0

Compiler.........: Pelles ISO C Compiler 2.70
xHarbour Version.: xHarbour build 0.99.70 Intl. (SimpLex)
Build Date.......: Dec 20 2006 13:26:02


Thanks,
-- Robert



Ron Pinkas wrote:
> Robert,
>
>> However, in my "real-world" program,
>> ...
>> Does saving and restoring plain vanilla character type variables to and
>> from .mem files not work in xHb?
>
> Not that we are aware of. Unless you can show us how to replicate I feel
> confident this must be an application issue rather than xHarbour issue.
>
> Ron
>
>

Robert

> However, this same code in a test stub in my application does not behave
> as expected.

Unless you can show us how to reproduce it in a reduced sample, ther's not
much we can do.

Ron

Ok, I took a chance that someone may know of a "known issue"
with one of the libraries.

-- Robert

Ron Pinkas wrote:
> Robert
>
>> However, this same code in a test stub in my application does not behave
>> as expected.
>
> Unless you can show us how to reproduce it in a reduced sample, ther's not
> much we can do.
>
> Ron
>
>

Robert

Did u try including these same libraries in the test program ?

Claudio

On Nov 1, 12:43 pm, chersz...@gmail.com wrote:
> Robert
>
> Did u try including these same libraries in the test program ?
>
> Claudio

Yes Claudio. I thought of that. They are not in the same order, does
that matter?

-- Robert