Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!usc!hacgate!ashtate!dbase!dukel
From: dukel@dbase.UUCP (Duke Luper)
Newsgroups: comp.databases
Subject: Re: dBASE IV -- Trials and Tribulations
Keywords: bugs
Message-ID: <169@dbase.UUCP>
Date: 20 Jul 89 02:26:39 GMT
References: <2071@hub.UUCP>
Organization: Ashton Tate Devlopment Center Glendale, Calif.
Lines: 198

In article <2071@hub.UUCP>, erbo@lime.ucsb.edu (Eric J. Bowersox) writes:
> Sorry if these bugs have appeared in this newsgroup before, but _I_ cer-
> tainly haven't seen them.
> 
> At my workplace, I am currently engaged in what amounts to almost a complete
> rewrite of a system for expense tracking that I had written some time
> earlier in dBASE III Plus.  The new version is being written in dBASE IV,
> and uses many of the neat features of that system (like pulldown menus and
> .MDX files), but in the process, I have run into some very frustrating
> system bugs.  Here are a couple I haven't heard mentioned.
> 
> BUG #1:	The Case of the Missing Procedure  (or: Son of Line Eater? :-) )
> 
> If you have a .PRG file with more than about 8 procedures in it, and you
> try to call the last procedure in that file, dBASE won't find it, and will
> hand you a "File does not exist" error.
> 
> WORKAROUND: Easy.  Just place a dummy procedure at the very end of each
> file that might have a large number of procedures in it, like:
> 
> PROCEDURE Blort
> *** Never call Blort!
> RETURN 
> 
> Unfortunately, this bug also affects generated report and label forms,
> since the code generator generates dBASE code, and that code has quite a
> few procedures in it, the last one of which (Reset) is affected by this bug.
> There are two things you can do with this:  edit the .FRG/.LBG files directly
> to insert the aforementioned dummy procedure (which you have to then do every
> time you re-generate the report), or (if you have the Developer's Edition)
> edit the templates to include that procedure at the end.  Since we do have
> the "Gold" edition, I chose the latter course, and it works fine.
> 
> (Postscript:  I looked at one of the .DBO files under Norton Utilities, and
> it seems that, at the end of the file, they have some sort of jump table
> showing where all the procedures are; the last procedure was missing from
> this table.  So, apparently, the compiler is just forgetting to stick that
> last entry in.  Or am I off base here?)
> 

Attempt to find BUG1:  Now, I'm not doubting that this happened to you.  I
just wanted to try it for myself and report to you my findings.  I ran the
following program:

* DUKE.PRG

do 1
do 2
do 3
do 4
do 5
do 6
do 7
do 8
do 9
do 10
do 11
do 12
do 13
do 14
do 15
do 16
do 17 
do 18
do 19
do 20
return

proc 1
? "this is proc 1"
return

proc 2
? "this is proc 2"
return
.
.
.
proc 20
? "this is proc 20"
return
* EOF: duke.prg

Here is the output:

this is test 1
this is test 2
this is test 3
this is test 4
this is test 5
this is test 6
this is test 7
this is test 8
this is test 9
this is test 10
.
.
this is test 19
this is test 20

Unfortunately, I couldn't reproduce it.  I also tried SET PROC TO DUKE and
removed all of the DO's and the first RETURN from DUKE.PRG and placed them
in TEST.PRG and ran TEST.PRG.  The output was the same.  I am running dBASE 1.0
on a Novell network (SFT Netware 286 V2.12) on a Compaq 386/16 with a HICARD.

> BUG #2: PLAYing Loop-the-Loop with MACROs
> 
> At one point in my application, I wanted to send a certain number of down-
> arrow keys to the keyboard, but that number might vary at certain times (it
> was to position the light-bar of a POPUP menu on a certain item).  So, I
> used the Tools/Macros (or something like that) menu in the Control Center to
> define a macro consisting of one down arrow key, called DOWNARROW.  Now, with
> that macro suitably loaded in my program, you would think the right thing to do would be:
> 
> I = 1
> DO WHILE I <= NDOWNS	&& the number of down arrows I want
>   PLAY MACRO DOWNARROW
>   I = I + 1
> ENDDO
> 
> Right? WRONG!  Apparently, on the second iteration of this loop, dBASE stopped
> my program with an error about "recursive macros" or somesuch(I don't remember
> the exact error message, but it was very irritating).  My guess is it doesn't
> like to see the same PLAY MACRO twice in a row.

I tried this test case on 1.0 multi-user version on Novell too and could not
reproduce the bug (unfortunately):

restore macros from test.key     && contains DOWNARROW as you described
use testdb1
i = 1
ndowns = 10
do while i <= ndowns
   play macro downarrow
   i = i+1
enddo
browse
return

Since successive PLAY MACRO statements load on a LIFO basis (refer to the
language reference manual page 2-196), then we would suspect to see the
BROWSE screen and the cursor move down to the 11th record (which it did 
without a problem).  I BELIEVE YOU that it happened to you, but my environment
was apparently not set up in a manner to catch the bug.

> 
> WORKAROUND:  In this case, it wasn't so bad; I just had to remember my binary.
> I defined three more macros consisting of two, four, and eight down arrow
> keys, called DOWN2, DOWN4, and DOWN8 respectively.  Now my code looked like
> this:
> 
> I = NDOWNS
> IF I >= 8
>   PLAY MACRO DOWN8
>   I = I - 8
> ENDIF
> IF I >= 4
>   PLAY MACRO DOWN4
>   I = I - 4
> ENDIF
> IF I >= 2
>   PLAY MACRO DOWN2
>   I = I - 2
> ENDIF
> IF I >= 1
>   PLAY MACRO DOWNARROW
>   I = I - 1
> ENDIF
> 
> Of course, this means you can't play more than 15 down arrows this way, but
> since I didn't even need _that_ many maximum, I let it go.  Besides, this
> method is extendable if necessary.  Even better, though, would have been
> an "ACTIVATE POPUP name BAR number" syntax, similar to "ACTIVATE MENU name
> PAD pad_name."
> 
> Now, the obligatory disclaimer:  I am not an Ashton-Tate affiliate in any
> way, shape, or form, except as YAPSWDBIV (yet another programmer struggling
> with dBASE IV), and I sincerely feel that, as long as I can keep hacking
> around the difficulties, the advantages of the new system greatly outweigh
> the disadvantages, and I will definitely be interested when A-T ships their
> v.1.1.  So, no flames from the A-T-bashers, please!
> 
> Hope someone, somewhere, can use this :-) :-) :-).
> 
> | Disclaimer:  This posting is definitive.  Reality may have got it wrong.    |
> | * Eric J. Bowersox (ERBO) *  LIVE! from Isla Vista, California!             |
> | erbo@cornu.ucsb.edu ...!{ucbvax,ucsd}!ucsbcsl!cornu!erbo                    |
> | If wishes were DRAMs, I don't think we would worry about the Japanese. -me  |

Good luck Eric.  Sorry I couldn't have been of more help.  If I could have 
reproduced it, I would have checked our tracking system here at AT and entered
a bug report.  

Duke Luper
Consultant to Ashton-Tate

I don't think I have to disclaim anything I've said but just in case, they are
my views and not Ashton-Tate's.  After all, what are Ashton-Tate's views?