Migration from 5.2e to xHarbour : Error BASE/1003 variable does not exist GETLIST

[CCH]

Hi David and other xHarbour/Harbour Gurus

Having resolved all unresolved external reference , I finally managed
to recompile an actual DOS-based CA-Clipper EXE to a XHarbour W32 EXE,
the next question is does it work

1) Launch FAS.EXE... so far so good
2) Input User Name & press enter, it bombs with the message

Error BASE/1003 variable does not exist GETLIST
Error at ...: MAIN_PASS(1051) in Module: FAS_MAIN.PRG
Called from : PASS_SCR(234) in Module: FAS_MAIN.PRG
Called from : MAIN(125) in Module: FAS_MAIN.PRG

I then relaunched FAS4DOS.EXE and it works perfectly...

Any suggestions ?



----------------------------- xHarbour Error Log
------------------------------

Date...............: 26/02/2009
Time...............: 21:56:06

Application name...: FAS
Workstation name...: DELL4CCH
Available memory...: 1369588
Current disk.......: C
Current directory..: xHB\Projects\FAS
Free disk space....: 2531098624

Operating system...: Windows XP Professional 5.01.2600 Service Pack 3
xHarbour version...: xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6220)
xHarbour built on..: Sep 30 2008 14:36:42
C/C++ compiler.....: Pelles ISO C Compiler 2.70
Multi Threading....: NO
VM Optimization....: 0

Current Area ......:1

-------------------------- Environmental Information
--------------------------

SET ALTERNATE......: OFF
SET ALTFILE........:
SET AUTOPEN........: ON
SET AUTORDER.......: 0
SET AUTOSHARE......: 0
SET BACKGROUNDTASKS: OFF
SET BACKGROUNDTICK.: 1000
SET BELL...........: OFF
SET BLINK..........: .F.
SET CANCEL.........: ON
SET CENTURY........: ON
SET COLOR..........: W/R,R+/W,N/N,N/N,R+/W
SET CONFIRM........: ON
SET CONSOLE........: ON
SET COUNT..........: 0
SET CURSOR.........: 1
SET DATE FORMAT....: DD/MM/YYYY
SET DBFLOCKSCHEME..: 0
SET DEBUG..........: OFF
SET DECIMALS.......: 2
SET DEFAULT........:
SET DEFEXTENSIONS..: ON
SET DELETED........: OFF
SET DELIMCHARS.....: ::
SET DELIMETERS.....: OFF
SET DEVICE.........: SCREEN
SET DIRCASE........: 0
SET DIRSEPARATOR...: \
SET EOL............: 13
SET EPOCH..........: 1960
SET ERRORLOG.......: ERROR.LOG,.F.
SET ERRORLOOP......: 8
SET ESCAPE.........: OFF
SET EVENTMASK......: 128
SET EXACT..........: OFF
SET EXCLUSIVE......: OFF
SET EXIT...........: OFF
SET EXTRA..........: OFF
SET EXTRAFILE......:
SET FILECASE.......: 0
SET FIXED..........: OFF
SET FORCEOPT.......: OFF
SET HARDCOMMIT.....: ON
SET IDLEREPEAT.....: ON
SET INSERT.........: OFF
SET INTENSITY......: ON
SET LANGUAGE.......: EN
SET MARGIN.........: 0
SET MBLOCKSIZE.....: 0
SET MCENTER........: OFF
SET MESSAGE........: 0
SET MFILEEXT.......:
SET OPTIMIZE.......: ON
SET OUTPUTSAFETY...: ON
SET PATH...........:
SET PRINTER........: OFF
SET PRINTERJOB.....:
SET PRINTFILE......: PRN
SET SCOREBOARD.....: OFF
SET SCROLLBREAK....: ON
SET SOFTSEEK.......: OFF
SET STRICTREAD.....: OFF
SET TRACE..........: ON
SET TRACEFILE......: TRACE.LOG
SET TRACESTACK.....: 2
SET TRIMFILENAME...: .F.
SET TYPEAHEAD......: 50
SET UNIQUE.........: OFF
SET VIDEOMODE......: 0
SET WRAP...........: ON

---------------------------Detailed Work Area
Items----------------------------

Work Area No ......: 1
Alias .............: FASCODEP
Current Recno .....: 1
Current Filter ....:
Relation Exp. .....:
Index Order .......: 0
Active Key ........:


-------------------- Internal Error Handling Information
---------------------

Subsystem Call ....: BASE
System Code .......: 1003
Default Status ....: .F.
Description .......: Variable does not exist
Operation .........: GETLIST
Arguments .........:
Involved File .....:
Dos Error Code ....: 0

Trace Through:
----------------
MAIN_PASS : 1,051 in Module: FAS_MAIN.PRG
PASS_SCR : 234 in Module: FAS_MAIN.PRG
MAIN : 125 in Module: FAS_MAIN.PRG

[Patrice]

Post by CCH
Hi David and other xHarbour/Harbour Gurus
Having resolved all unresolved external reference , I finally managed
to recompile an actual DOS-based CA-Clipper EXE to a XHarbour W32 EXE,
the next question is does it work
1) Launch FAS.EXE... so far so good
2) Input User Name & press enter, it bombs with the message
Error BASE/1003 variable does not exist GETLIST
Error at ...: MAIN_PASS(1051) in Module: FAS_MAIN.PRG
Called from : PASS_SCR(234) in Module: FAS_MAIN.PRG
Called from : MAIN(125) in Module: FAS_MAIN.PRG
I then relaunched FAS4DOS.EXE and it works perfectly...
Any suggestions ?

GETLIST is a variable in which clipper stores all the GETs you do before
a READ.
Usually, it is automatically created by clipper, it should be the same
in XHarbour.

For some reason, Xharbour don't see it when you do your fist GET at
MAIN_PASS line 1051.

I think only the source code can help to tell you what append.

Patrice

[CCH]

Hi Patrice

The code snippet are as follows :-

static function MAIN_pass()

// 7/6/98
memvar mmaster
//
local oldarea
local oldscr
local mlevel := 0
local mpassword := space( 10 )
//
local nCounter := 0
// 7/6/98
local cPassWord
public mUser

//open password file
select 0
if !NETUSE( 'FASCODEP.CHC', .f., 5 )
close DATA
return .f.
endif

while nCounter <= 3
nCounter ++
//enter user name
oldscr := savescreen( 18, 0, 21, 40 )
scroll( 18, 0, 20, 40, 0 )
*SET COLOR TO N/W,X
dispbox( 18, 0, 20, 40 )
@ 19, 1 say "Enter User Name => " ;
get muser
setcursor( 1 )
read
setcursor( 0 )
INVER_OFF()

if lastkey() = 27 //2/2/97 lh.OR. muser=space
(10)
restscreen( 18, 0, 21, 40, oldscr )
return .f.
endif
//check for existence of password
locate for FASCODEP->USER = muser
if eof()
? chr( 7 )
alert( "No such User Name !" )
restscreen( 18, 0, 21, 40, oldscr )
if nCounter = 3
return .f.
endif
else
cPassword := DECRYPT( FASCODEP->PASSWORD )
exit
endif
enddo

Post by CCH
Hi David and other xHarbour/Harbour Gurus
Having resolved all unresolved external reference , I finally managed
to recompile an actual DOS-based CA-Clipper EXE to a XHarbour W32 EXE,
the next question is does it work
1) Launch FAS.EXE... so far so good
2) Input User Name & press enter, it bombs with the message
Error BASE/1003 variable does not exist GETLIST
Error at ...: MAIN_PASS(1051) in Module: FAS_MAIN.PRG
Called from : PASS_SCR(234) in Module: FAS_MAIN.PRG
Called from : MAIN(125) in Module: FAS_MAIN.PRG
I then relaunched FAS4DOS.EXE and it works perfectly...
Any suggestions ?

        GETLIST is a variable in which clipper stores all the GETs you do before
a READ.
        Usually, it is automatically created by clipper, it should be the same
in XHarbour.
        For some reason, Xharbour don't see it when you do your fist GET at
MAIN_PASS line 1051.
        I think only the source code can help to tell you what append.
Patrice

[Michael Hagl]

Hi

insert this line in Main_pass()

Local getlist := {}



"CCH" <***@gmail.com> schrieb im Newsbeitrag news:56063cf3-e01f-45a3-8f59-***@n30g2000vba.googlegroups.com...
Hi Patrice

The code snippet are as follows :-

static function MAIN_pass()

// 7/6/98
memvar mmaster
//
local oldarea
local oldscr
local mlevel := 0
local mpassword := space( 10 )
//
local nCounter := 0
// 7/6/98
local cPassWord
public mUser

//open password file
select 0
if !NETUSE( 'FASCODEP.CHC', .f., 5 )
close DATA
return .f.
endif

while nCounter <= 3
nCounter ++
//enter user name
oldscr := savescreen( 18, 0, 21, 40 )
scroll( 18, 0, 20, 40, 0 )
*SET COLOR TO N/W,X
dispbox( 18, 0, 20, 40 )
@ 19, 1 say "Enter User Name => " ;
get muser
setcursor( 1 )
read
setcursor( 0 )
INVER_OFF()

if lastkey() = 27 //2/2/97 lh.OR. muser=space
(10)
restscreen( 18, 0, 21, 40, oldscr )
return .f.
endif
//check for existence of password
locate for FASCODEP->USER = muser
if eof()
? chr( 7 )
alert( "No such User Name !" )
restscreen( 18, 0, 21, 40, oldscr )
if nCounter = 3
return .f.
endif
else
cPassword := DECRYPT( FASCODEP->PASSWORD )
exit
endif
enddo

Post by Patrice

Post by CCH
Hi David and other xHarbour/Harbour Gurus
Having resolved all unresolved external reference , I finally managed
to recompile an actual DOS-based CA-Clipper EXE to a XHarbour W32 EXE,
the next question is does it work
1) Launch FAS.EXE... so far so good
2) Input User Name & press enter, it bombs with the message
Error BASE/1003 variable does not exist GETLIST
Error at ...: MAIN_PASS(1051) in Module: FAS_MAIN.PRG
Called from : PASS_SCR(234) in Module: FAS_MAIN.PRG
Called from : MAIN(125) in Module: FAS_MAIN.PRG
I then relaunched FAS4DOS.EXE and it works perfectly...
Any suggestions ?

GETLIST is a variable in which clipper stores all the GETs you do before
a READ.
Usually, it is automatically created by clipper, it should be the same
in XHarbour.
For some reason, Xharbour don't see it when you do your fist GET at
MAIN_PASS line 1051.
I think only the source code can help to tell you what append.
Patrice

[Ron Pinkas]

Since we are not aware of any reason such basic feature of Clipper would not
work with xHarbour, I'd prefer and recommend, finding the cause rather than
circumvent it with a workaround. Any such Clipper code must work perfectly
in xHarbour withOUT any modifications. I'm confident the true cause of the
problem can and should be found. It only requires basic debugging skills.

Ron

Post by Michael Hagl
Hi
insert this line in Main_pass()
Local getlist := {}
Hi Patrice
The code snippet are as follows :-
static function MAIN_pass()
// 7/6/98
memvar mmaster
//
local oldarea
local oldscr
local mlevel := 0
local mpassword := space( 10 )
//
local nCounter := 0
// 7/6/98
local cPassWord
public mUser
//open password file
select 0
if !NETUSE( 'FASCODEP.CHC', .f., 5 )
close DATA
return .f.
endif
while nCounter <= 3
nCounter ++
//enter user name
oldscr := savescreen( 18, 0, 21, 40 )
scroll( 18, 0, 20, 40, 0 )
*SET COLOR TO N/W,X
dispbox( 18, 0, 20, 40 )
@ 19, 1 say "Enter User Name => " ;
get muser
setcursor( 1 )
read
setcursor( 0 )
INVER_OFF()
if lastkey() = 27 //2/2/97 lh.OR. muser=space
(10)
restscreen( 18, 0, 21, 40, oldscr )
return .f.
endif
//check for existence of password
locate for FASCODEP->USER = muser
if eof()
? chr( 7 )
alert( "No such User Name !" )
restscreen( 18, 0, 21, 40, oldscr )
if nCounter = 3
return .f.
endif
else
cPassword := DECRYPT( FASCODEP->PASSWORD )
exit
endif
enddo

Post by Patrice

Post by CCH
Hi David and other xHarbour/Harbour Gurus
Having resolved all unresolved external reference , I finally managed
to recompile an actual DOS-based CA-Clipper EXE to a XHarbour W32 EXE,
the next question is does it work
1) Launch FAS.EXE... so far so good
2) Input User Name & press enter, it bombs with the message
Error BASE/1003 variable does not exist GETLIST
Error at ...: MAIN_PASS(1051) in Module: FAS_MAIN.PRG
Called from : PASS_SCR(234) in Module: FAS_MAIN.PRG
Called from : MAIN(125) in Module: FAS_MAIN.PRG
I then relaunched FAS4DOS.EXE and it works perfectly...
Any suggestions ?

GETLIST is a variable in which clipper stores all the GETs you do before
a READ.
Usually, it is automatically created by clipper, it should be the same
in XHarbour.
For some reason, Xharbour don't see it when you do your fist GET at
MAIN_PASS line 1051.
I think only the source code can help to tell you what append.
Patrice

[Eugene F.]

Search all you source code for "RELEASE" to make sure that you're not
deleting the GetList variable yourself.

Do you use Custom Readers?

Just my $0.02 (or less).

Eugene

[CCH]

Hi Eugene

Post by Eugene F.
Search all you source code for "RELEASE" to make sure that you're not
deleting the GetList variable yourself.

CCH : Just checked, no RELEASE or CLEAR GETS euther

Post by Eugene F.
Do you use Custom Readers?

CCH: Nope

Post by Eugene F.
Just my $0.02 (or less).
Eugene

CCH
Clipper... Clipper...Clipper
http://cch4clipper.blogspot.com

[Ron Pinkas]

By some chance do you happen to have a PROCEDURE or FUNCTION named ClipInit?

Post by CCH
Hi Eugene

Post by Eugene F.
Search all you source code for "RELEASE" to make sure that you're not
deleting the GetList variable yourself.

CCH : Just checked, no RELEASE or CLEAR GETS euther

Post by Eugene F.
Do you use Custom Readers?

CCH: Nope

Post by Eugene F.
Just my $0.02 (or less).
Eugene

CCH
Clipper... Clipper...Clipper
http://cch4clipper.blogspot.com

[CCH]

Hi Ron

Post by Ron Pinkas
By some chance do you happen to have a PROCEDURE or FUNCTION named ClipInit?

CCH: Not in my PRGs nor in SuperLib PRGs
But I found it in FAS.MAP, a file generated by xHarbour Builder


CCH
http://cch4clipper.blogspot.com

[Ron Pinkas]

Post by CCH

Post by Ron Pinkas
By some chance do you happen to have a PROCEDURE or FUNCTION named ClipInit?

CCH: Not in my PRGs nor in SuperLib PRGs
But I found it in FAS.MAP, a file generated by xHarbour Builder

This is the Link MAP file. What module does it say ClipInit was linked from?

Ron

[CCH]

Hi Ron

Post by Ron Pinkas

Post by CCH

Post by Ron Pinkas
By some chance do you happen to have a PROCEDURE or FUNCTION named ClipInit?

CCH: Not in my PRGs nor in SuperLib PRGs
But I found it in FAS.MAP, a file generated by xHarbour Builder

This is the Link MAP file. What module does it say ClipInit was linked from?

CCH:

0001:0006b7e0 _HB_FUN_CLIPINIT 0046c7e0 f
xHB:harbinit.obj


CCH
http://cch4clipper.blogspot.com

[Ron Pinkas]

CCH,

This shows that system module xhb.lib:ClipInit is indeed linked to your
application, and thus upon startup a PUBLIC variable GetList is created as
an empty array. I must conclude that somewhere in your application, you must
have some form of the RELEASE command which releases this system variable.
I'd look for all instances of the word:

RELE

You might encounter a RELEASE ALL or other such command which will explain
the issue.

Ron

Post by CCH
Hi Ron

Post by Ron Pinkas

Post by CCH

Post by Ron Pinkas
By some chance do you happen to have a PROCEDURE or FUNCTION named ClipInit?

CCH: Not in my PRGs nor in SuperLib PRGs
But I found it in FAS.MAP, a file generated by xHarbour Builder

This is the Link MAP file. What module does it say ClipInit was linked from?

0001:0006b7e0 _HB_FUN_CLIPINIT 0046c7e0 f
xHB:harbinit.obj
CCH
http://cch4clipper.blogspot.com

[CCH]

Hi Ron

On Feb 27, 10:07 pm, "Ron Pinkas"

Post by Ron Pinkas
CCH,
This shows that system module xhb.lib:ClipInit is indeed linked to your
application, and thus upon startup a PUBLIC variable GetList is created as
an empty array. I must conclude that somewhere in your application, you must
have some form of the RELEASE command which releases this system variable.
  RELE
You might encounter a RELEASE ALL or other such command which will explain
the issue.
Ron

CCH: I have just scan all my PRGs for the FAS project an dthere is
only 1 unit from SuperLib, s_forml.prg which contains the wildcard
'RELE'

clear typeahead
restore screen from m->screen2
release screen2

Is this the issue ?

BTW, I have noticed that most PD functions always seem to have LOCAL
getlist:={} declared

[Ron Pinkas]

CCH,

Post by CCH
CCH: I have just scan all my PRGs for the FAS project an dthere is
only 1 unit from SuperLib, s_forml.prg which contains the wildcard
'RELE'
clear typeahead
restore screen from m->screen2
release screen2
Is this the issue ?

Doesn't seems that way, but as a side note IMO this is a low quality code.

How about the command RESTORE [FROM] - please searshe all instances of REST.

Post by CCH
BTW, I have noticed that most PD functions always seem to have LOCAL
getlist:={} declared

This is perfectly OK.

Ron

[CCH]

Hi Ron

I found the culprit as there was a
RESTORE FROM <FILENAME>

By adding ADDITIVE as in
RESTORE FROM <FILENAME> ADDITIVE

& removing LOCAL getlist:={} did not trigger the BASE/1003 error.


BTW, I had already spent a whole day to add LOCAL getlist:={}
throughout this huge accounting application :-(
So, I'll just leave the LOCAL getlist declaration as it is,

Thanx for your persistence in tracking this seemingly mysterious bug.


CCH
http://cch4clipper.blogspot.com

Post by Ron Pinkas
CCH,

Post by CCH
CCH: I have just scan all my PRGs for the FAS project an dthere is
only 1 unit from SuperLib, s_forml.prg which contains the wildcard
'RELE'
clear typeahead
restore screen from m->screen2
release screen2
Is this the issue ?

Doesn't seems that way, but as a side note IMO this is a low quality code.
How about the command RESTORE [FROM] - please searshe all instances of REST.

Post by CCH
BTW, I have noticed that most PD functions always seem to have LOCAL
getlist:={} declared

This is perfectly OK.
Ron

[FP]

Post by CCH
BTW, I had already spent a whole day to add LOCAL getlist:={}
throughout this huge accounting application :-(
So, I'll just leave the LOCAL getlist declaration as it is,

Ron told you not to do that !

I suggest you to remove the "local GetList" as you may encounter other
side-effects.

Francesco

[CCH]

Hi Francesco

Post by FP

Post by CCH
BTW, I had already spent a whole day to add LOCAL getlist:={}
throughout this huge accounting application :-(
So, I'll just leave the LOCAL getlist declaration as it is,

Ron told you not to do that !

CCH: Yes, he did say that :-)
But the effort was worth it as I have now a 32-bit Windows version of
my Accounting system for DOS and it only took about 3 days of hard
work.

Post by FP
I suggest you to remove the "local GetList" as you may encounter other
side-effects.

CCH: What are the potential side-effects ?

Post by FP
Francesco

[Patrice]

Hi CCH,

Post by CCH

Post by FP
I suggest you to remove the "local GetList" as you may encounter other
side-effects.

I don't suggest if you understand what append.

Post by CCH
CCH: What are the potential side-effects ?

I am using the "local getlist" in every function that display things on
screen BECAUSE of the side effects.

Why I do this? because it is practical.

Exemple: in a screen I have to type a customer Id, I can cascade from
inside a GET to call a lookup module without killing my actual GETLIST.

Exemple: when I GET a coded value, I use the valid clause to refresh the
screen on fly and the decoding of the value without killing my actual GETLIST.
See below.

function myscreen(reading)
local getlist:={}

@ 2, 2 say "Type the code :"
@ 2,20 get myvalue picture "!" valid mycheck(myvalue) .and.
myscreen(.F.)
do case
case myvalue="A"
@ 2,25 say "Alpha"
case myvalue="B"
@ 2,25 say "beta "
case myvalue="O"
@ 2,25 say "omega"
otherwise
@ 2,25 say "?????"
endcase

...

if reading
read
endif

return .T.

Patrice

[FP]

Post by Patrice
I am using the "local getlist" in every function that display things on
screen BECAUSE of the side effects.

Hi Patrice,
what you do is extremely correct. I also do this way in my code... it's
the only way !

The OP was converting a working application.. and it should have worked
without any change. The fact that it was not working was an error.

Francesco

[Patrice]

Hi Francesco,

CCH was asking what are the side effects, my response is to show him an
interesting side effect.

Patrice

Post by FP

Post by Patrice
I am using the "local getlist" in every function that display things on
screen BECAUSE of the side effects.

Hi Patrice,
what you do is extremely correct. I also do this way in my code... it's
the only way !
The OP was converting a working application.. and it should have worked
without any change. The fact that it was not working was an error.
Francesco

[FP]

As said by Ron Pinkas, the original GetList declaration is a PUBLIC so
it is visible in all code levels. If a program runs this way without
problems means that it is written to not use nested gets and that I can
access GetList in any code.

So suppose that for some reason you do something with GetList in a function.

If you redefined GetList as Local, in the function you may be referring
the PUBLIC GetList not the LOCAL one....

All this to say: it's perfectly ok if you do a Local GetList because you
know what you are doing.
It's NOT safe to add Local GetList without checking if and how GetList
object is "used" in the code.

[Ron Pinkas]

EXACTLY!

Of course I prefer code that was *designed* to work with LOCAL GetList, but
it must be intentional, knowing the differences.

Ron

As said by Ron Pinkas, the original GetList declaration is a PUBLIC so it
is visible in all code levels. If a program runs this way without problems
means that it is written to not use nested gets and that I can access
GetList in any code.
So suppose that for some reason you do something with GetList in a function.
If you redefined GetList as Local, in the function you may be referring
the PUBLIC GetList not the LOCAL one....
All this to say: it's perfectly ok if you do a Local GetList because you
know what you are doing.
It's NOT safe to add Local GetList without checking if and how GetList
object is "used" in the code.

[CCH]

Hi Patrice

My experience thus far is that after adding ADDITIVE to RESTORE FROM,
i need not need to add local getlist:=() anymore.
However, when I used HMG, I had to remove the said declaration in
order to compile.

CCH
http://cch4clipper.blogspot.com

        Hi CCH,

Post by CCH

Post by FP
I suggest you to remove the "local GetList" as you may encounter other
side-effects.

        I don't suggest if you understand what append.

Post by CCH
CCH: What are the potential side-effects ?

        I am using the "local getlist" in every function that display things on
screen BECAUSE of the side effects.
        Why I do this? because it is practical.
        Exemple: in a screen I have to type a customer Id, I can cascade from
inside a GET to call a lookup module without killing my actual GETLIST.
        Exemple: when I GET a coded value, I use the valid clause to refresh the
screen on fly and the decoding of the value without killing my actual GETLIST.
See below.
function myscreen(reading)
        local getlist:={}
myscreen(.F.)
        do case
        case myvalue="A"
        case myvalue="B"
        case myvalue="O"
        otherwise
        endcase
        ...
        if reading
                read
        endif
        return .T.
Patrice

[Ron Pinkas]

There's no need to add ADDITIVE to the RESTORE FROM command any longer. The
RESTORE FROM command has been fixed to be Clipper compatible. Be advised
that adding ADDITIVE, may cause unintentional side effects.

Ron

Post by CCH
Hi Patrice
My experience thus far is that after adding ADDITIVE to RESTORE FROM,
i need not need to add local getlist:=() anymore.
However, when I used HMG, I had to remove the said declaration in
order to compile.
CCH
http://cch4clipper.blogspot.com

Post by Patrice
Hi CCH,

Post by CCH

Post by FP
I suggest you to remove the "local GetList" as you may encounter other
side-effects.

I don't suggest if you understand what append.

Post by CCH
CCH: What are the potential side-effects ?

I am using the "local getlist" in every function that display things on
screen BECAUSE of the side effects.
Why I do this? because it is practical.
Exemple: in a screen I have to type a customer Id, I can cascade from
inside a GET to call a lookup module without killing my actual GETLIST.
Exemple: when I GET a coded value, I use the valid clause to refresh the
screen on fly and the decoding of the value without killing my actual GETLIST.
See below.
function myscreen(reading)
local getlist:={}
@ 2, 2 say "Type the code :"
@ 2,20 get myvalue picture "!" valid mycheck(myvalue) .and.
myscreen(.F.)
do case
case myvalue="A"
@ 2,25 say "Alpha"
case myvalue="B"
@ 2,25 say "beta "
case myvalue="O"
@ 2,25 say "omega"
otherwise
@ 2,25 say "?????"
endcase
...
if reading
read
endif
return .T.
Patrice

[Eugene F.]

Ron,

Post by Ron Pinkas
There's no need to add ADDITIVE to the RESTORE FROM command any longer. The
RESTORE FROM command has been fixed to be Clipper compatible. Be advised
that adding ADDITIVE, may cause unintentional side effects.

The above is true only when the latest CVS is used, right?

[Ron Pinkas]

Post by Eugene F.

Post by Ron Pinkas
There's no need to add ADDITIVE to the RESTORE FROM command any longer. The
RESTORE FROM command has been fixed to be Clipper compatible. Be advised
that adding ADDITIVE, may cause unintentional side effects.

The above is true only when the latest CVS is used, right?

Yes, and it will be available in the upcoming release, which should be
available next week. It's also included in the just released PUBLIC BETA
from xHarbour.com

Ron

[Ron Pinkas]

CCH,

Post by CCH
I found the culprit as there was a
RESTORE FROM <FILENAME>

:-) - now it makes sense.

Post by CCH
By adding ADDITIVE as in
RESTORE FROM <FILENAME> ADDITIVE
& removing LOCAL getlist:={} did not trigger the BASE/1003 error.

I've just fixed xHarbour to be Clipper compatible with this undocumented
feature of Clipper (protecting M->GetList from a RESTORE FROM ...), so that
you should now be able to compile your original, unmodified Clipper code.

2009-02-27 15:03 UTC-0430 Ron Pinkas <ron/at/xharbour.com>
* source\vm\memvars.c
! Fixed __M[V]RESTORE() to be Clipper compatible.
Clipper protects the value of GetList if it exists, when ADDITIVE not
specified

Post by CCH
BTW, I had already spent a whole day to add LOCAL getlist:={}
throughout this huge accounting application :-(
So, I'll just leave the LOCAL getlist declaration as it is,

This is OK *only* if you understand the change and is sure that your code
doesn't assume global visibility for GetList, and or no code is expecting a
valid M[EMVAR]->GetList

Post by CCH
Thanx for your persistence in tracking this seemingly mysterious bug.

Thank you - thanks to your assistance we have just improved compatibility,
which is why it's so important to NEVER accept any incompatibility without
truly understanding the cause.

Ron

[CCH]

Hi Michael

Post by Michael Hagl
Hi
insert this line in Main_pass()
Local getlist := {}

CCH: Yup, it works !

[CCH]

Hi Michael

On further testing, I am getting the BASE/1003, Variable does not
exist getlist whenever there are GETS
So, I am adding Local getlist := {} in any function containing GETS

Regards

CCH
http://cch4clipper.blogspot.com

[Ron Pinkas]

Post by CCH
On further testing, I am getting the BASE/1003, Variable does not
exist getlist whenever there are GETS
So, I am adding Local getlist := {} in any function containing GETS

Please don't.

Your code must work as-is, please help us help you find the real problem.

Ron

[Maurício Faria]

Maybe a wrong or changed .CH or the search order of .CHs..
--
Maurício Faria

Post by Ron Pinkas

Post by CCH
On further testing, I am getting the BASE/1003, Variable does not
exist getlist whenever there are GETS
So, I am adding Local getlist := {} in any function containing GETS

Please don't.
Your code must work as-is, please help us help you find the real problem.
Ron

[Patrice]

On Thu, 26 Feb 2009 18:13:07 -0800 (PST), CCH <***@gmail.com> wrote:

you should link your app with the debugger and add a ALTD() as a first
step of your app.
the GETLIST must allready be there, and it become unavailable for some
reason that you have to find.

Patrice

Post by CCH
Hi Michael
On further testing, I am getting the BASE/1003, Variable does not
exist getlist whenever there are GETS
So, I am adding Local getlist := {} in any function containing GETS
Regards
CCH
http://cch4clipper.blogspot.com

[Patrice]

Hi CCH,

Don't see anything on this part of the code.

As Ron said you should launch the debuger and track the GETLIST
variable.
It become unavailable at some point.

Patrice