timk@xenitec.on.ca (Tim Kuehn) (10/30/89)
In article <1989Oct27.170621.27641@telotech.uucp> bsa@telotech.UUCP (Brandon S. Allbery) writes: >In article <1989Oct24.153944.29979@agate.berkeley.edu>, steve@violet (Steve Goldfield) writes: >+--------------- >| I declared a variable public in one program and set it to a >| value, but in the next program I ran the variable was declared >| not to have a value. I'm not strongly motivated to use FoxBase >| if the programming features I'm used to using don't work. >+--------------- > >As far as I've been able to tell, the MS-Doesn't versions of both FoxBase and >dBase III+ require that you declare a variable PUBLIC in *all* procedures that >want to use the public copy. This is in error - my standard "SETUP" procedures declare a bunch of PUBLIC variables that I use throughout the rest of the program, and the only place they are declared public is in the SETUP procedure. On the other hand, I have run into interesting problems debugging a program someone else had written that was crashing on a public statement all the time. Seems that a 'save to' and 'restore from' combination was saving and restoring some public variables it shouldn't have, and as a result when the program said 'Public <variables>' it'd phreak out. +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec.on.ca | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Satisfaction Guaranteed| +-----------------------------------------------------------------------------+