Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!hub!lime!erbo
From: erbo@lime.ucsb.edu (Eric J. Bowersox)
Newsgroups: comp.databases
Subject: dBASE IV -- Trials and Tribulations
Keywords: bugs
Message-ID: <2071@hub.UUCP>
Date: 16 Jul 89 10:15:42 GMT
Sender: news@hub.UUCP
Reply-To: erbo@cornu.ucsb.edu (Eric J. Bowersox)
Organization: UC Santa Barbara, Campus Club for Computer People (CCCP)
Lines: 100

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?)

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.

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  |