Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!samsung!munnari.oz.au!bruce!merlin!paulg From: paulg@resmel.bhp.com.au (Paul Gallagher) Newsgroups: comp.databases Subject: Re: dbase IV "popup" while editing data with "read" command Keywords: dbase, data entry Message-ID: <1991May4.104826.11179@resmel.bhp.com.au> Date: 4 May 91 10:48:26 GMT References: <881@imec.UUCP> <1991Apr5.164724.4798@dbase.A-T.COM> <1991Apr17.110913.7460@bhpmrl.oz.au> <1991Apr22.170319.24538@dbase.A-T.COM> <1991May4.063752.10314@resmel.bhp.com.au> Sender: usenet@resmel.bhp.com.au (USEnet nntp account) Organization: BHP Research - Melbourne Laboratories, AUSTRALIA Lines: 164 Alastair, THE ELUSIVE NESTED READ BUG cont'd ---------------------------------- I just realised that all of the code fragments in my previous message were tested with ~500kb free mem. To certify the results, I ran them through with 570kb free. In the process, I've managed to rationalise the situation. Operation of the following examples was consistent at both 500kb and 570kb free memory. Unless you require >70kb to re-enter the interpreter, a lack of memory hardly seems to be the problem. In these examples, I discovered that the PICTURE clause in the VALIDATED second level @..GET could be used to toggle between error/no error. Note that in some examples, removing the clause clears the problem, while in others, including it does the trick! (You may remember from my previous message that in a number of applications, I have used the MESSAGE clause to fix the problem) It also appears that a VALIDATED second level @..GET requires some kind of preceeding @..GET at the same level (see programs 5 & 6). Just when I thought I was coming to an understanding regarding the problem... To reiterate my previous conclusions: nesting reads with VALIDation is *flaky* ! Can you shed any light Alastair? Regards, Paulg. PS: I've seen you cop alot of flak on the net, usually unjustifiably. Don't let it get to you. There are too many hypocrits out there that on the one hand want frank and open discussion on subjects that matter, but don't hesitate to shoot down in flames anyone who (god forbid) voices an opinion (no matter how many disclaimers you attach, or biases you admit). ********************************************************* * PROGRAM 1: This demonstrates the type of operation I * want to code. This particular routine works OK unless * you remove the PICTURE "999" clause in which case * an "Unrecognised command code" error is generated on * return from getstr(). set talk off clear p_x =space(10) p_y =0 @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @10,20 GET p_x PICTURE "@s10" @11,20 GET p_y PICTURE "999" ; VALID REQUIRED p_y>0 ; ERROR "must be >0" read @ 6,5 SAY p_x color n/bg && this is just to be pretty - * it can be removed with no effect * on the results RETURN .t. ********************************************************* * PROGRAM 2: p_y>0 always fails, unless the * PICTURE "999" is removed in which case "unknown command * code" is generated on return from UDF set talk off clear p_x =space(10) p_y =0 @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @11,20 GET p_y PICTURE "999" ; VALID REQUIRED p_y>0 ; ERROR "must be >0" read RETURN .t. ********************************************************* * PROGRAM 3: A slight variation of program 1. It works! * set talk off clear p_x =space(10) p_y =space(1) @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @10,20 GET p_x PICTURE "@s10" @11,20 GET p_y ; VALID REQUIRED p_y$"YyNn" ; ERROR "[Y/N]" read @ 6,5 SAY p_x color n/bg && this is just to be pretty - * it can be removed with no effect * on the results RETURN .t. ********************************************************* * PROGRAM 4: A slight variation of program 3, but this * doesn't work at all - "Unknown command code" is reported * on return from getstr() set talk off clear p_x =space(10) p_y =space(1) @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @11,20 GET p_y ; VALID REQUIRED p_y$"YyNn" ; ERROR "[Y/N]" read RETURN .t. ********************************************************* * PROGRAM 5: Works only if the PICTURE "999" * clause is *removed* i.e. the opposite of program #. * Otherwise : "Unknown command code" on return from UDF. set talk off clear p_x =space(10) p_y =0 p_z =space(1) @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @10,20 GET p_z PICTURE "@s1" @11,20 GET p_y PICTURE "999" ; VALID REQUIRED p_y>0 ; ERROR "must be >0" read RETURN .t. ********************************************************** * PROGRAM 6: A variation on program 5, but this one works * only *with* the PICTURE "999" clause, otherwise * an "unrecognised command code" generated. set talk off clear p_x =space(10) p_y =0 p_z =space(10) @ 6,5 GET p_x PICTURE "@s10" ; VALID REQUIRED getstr() read RETURN FUNCTION getstr @10,20 GET p_z PICTURE "@s10" @11,20 GET p_y PICTURE "999" ; VALID REQUIRED p_y>0 ; ERROR "must be >0" read RETURN .t. >end of examples ************************************************