Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!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.063752.10314@resmel.bhp.com.au> Date: 4 May 91 06:37:52 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> Sender: usenet@resmel.bhp.com.au (USEnet nntp account) Organization: BHP Research - Melbourne Laboratories, AUSTRALIA Lines: 195 Alistair, I was interested to see your response to my mailing. It's good to get the _cause_ of a problem explained, but as you say, not much consolation. As you suggested, I have passed on the problem to our local A-T hotline, but I've included some of the fruits of my own investigation below. More of THAT problem latter... I'm impressed by the commitment that A-T management is showing, too. However, commitment<>success, but V1.1 is certainly a huge step in the right direction. On the whole it is a solid product. The only problems I have encountered are: (1) The nested read problem (2) MESSAGES often hang around after a READ has ended (my work-around has been to include a dummy [null] field at the end of the form, but this doesn't work if the user uses or to exit. Is there any better way?) (3) F-DRIVER v1.12 (part of the F-PROT anti-virus package) causes BUILD and RUNTIME to hang unless they reside in the current directory (i.e. they hang if accessed on the PATH). I have not encountered this interference with any other package. Niggles (not strictly problems) I have are : (1) The built in editor has to be one of the s-l-o-w-e-s-t pieces of junk I have ever come across! I accept your opinion that serious development warrants more than an XT, but really! This is just gratuitous slowness. I respect your decision to use a third party caching program - my question is why not do the same with the editor? There are plenty of programs out there that could be adapted at little cost. (2) Is BUILD/DBLINK meant for serious applications? (more than just "Hello, world"). I've tried 386 machines with 4Mb+ configured in every which way, but cannot build & link even the most basic application without getting an out-of-memory error. Niggles-to-be: (1) I believe A-T is planning to use some kind of VCPI/DPMI extender in a new release. I would have thought that Lotus' experience with 123 especially would have shot home the fact that nowdays, users (at least the ones I support) want XMS 2.0 or nothing. Of course, there are certain types of applications that will be able to survive in the marketplace and still use DOS/16M or similar (such as dedicated data-loggers), but I don't believe dBase belongs in this category. For sure, it means bowing to the whim of Microsoft (once again), but however distasteful this may be, I think the memory management coup has already been won and lost. THE ELUSIVE NESTED READ BUG cont'd ---------------------------------- NB: This was written before I read your message. Some of the comments can be discounted in light of the explaination. ---------------------------------- The code provided by our A-T hotline to "prove" that GET REQUIRED could not be nested: store space(1) to x,y @2,2 get x valid required myudf() error "wrong" read function myudf @3,3 get y valid y$"YN" error "really wrong" read return .t. NB: If you take out the "REQUIRED" keyword, it works! Alternatively, if y is numeric and the validation condition is something like y>0, it works! I was not particularly satisfied, especially since I had a heap of code that nested READs using VALID and VALID REQUIRED and in the most part I was able to get it to work (see my previous message). More importantly, I couldn't believe that such performance was in accordance with the dBase design intent. Since then, I've made the time to investigate the problem in more detail. The following routines demonstrate the inconsistent performance of dBase IV V1.1 in this area. ********************************************************* * PROGRAM 1: This demonstrates the type of operation I * want to code. This particular routine works OK. 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 RETURN .t. ********************************************************* * PROGRAM 2: A slight variation of program 1, but this * doesn't work - the use of "$" in validation uncovers * the problem. 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 RETURN .t. ********************************************************* * PROGRAM 3: "Unknown command code" on return from UDF. * Removing "REQUIRED" does not solve the problem. 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 4: A variation on program 3, but this one works! * All that has been changed is the length of memvar "p_z" 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 ************************************************ CONCLUSION: Using nested reads via VALID/VALID REQUIRED is very _flaky_. As demonstrated, it is not easy to identify a certain construct and say "THAT doesn't work, but THIS does". It is not dependant upon the use of REQUIRED, "$" in validation, MESSAGE (see my previous message), or the order and type of @..GET, but all of these factors _can_ contribute, and uncover the elusive nested read bug. On the other hand, it is possible to organise these constructs so that the routine does work.. a real black art. I guess what is needed is for A-T to determine whether nesting reads in this manner is indeed in accordance with the design specification. If so - fix it, if not - MAKE it part of the spec, coz its a real neat trick (useful too). Regards, Paulg. /\/\ Paul Gallagher, PC Support Officer, / / /\ Computer Systems Group, / / / \ BHP Research - Melbourne Laboratories / / / /\ \ 245 Wellington Rd Mulgrave Vic 3170 AUSTRALIA \ \/ / / / Phone : +61-3-560-7066, Fax : +61-3-561-6709 \ / / / ACSnet : paulg@resmel.bhp.com.au \/\/\/ : vggalp@resmel.bhp.com.au : paulg@bhpmrl.oz.au Now on AARnet.