peter@aucs.UUCP (Peter Steele) (09/09/88)
I'm a fairly new dBase III+ programmer and I've run into a problem
with procedure files that I can't seem to find a straightforward way
around. Logically, my program consists of a main program, a procedure
file consisting of a set of utilities used by various other procedure
files, as well as several other procedure files each dedicated to a
particular task. My problem is that when I'm in one of the "task"
solving procedure files, I cannot access any of the utility routines
because only one procedure file can be open at a time, and I have to
call these utility routines in a variety of places (several subroutine
calls deep). The only way I can see around this problem is either (a)
put all the utility routines in each of the task procedure files; (b)
put each utility routine in its own procedure file of the same name as the
utility routine; or (c) convert to Clipper.
Solution (a) isn't really feasible as I have quite a few utility routines
and I would exceed the 32 proceduree limit. I don't like (b) simply because
I don't want to have a bunch of little files cluttering up my account (as
well as the slower execution speed this approach causes having to load the
routines every time they're accessed). (c) seems to be my only solution.
This is okay because I intended to convert to Clipper at the end anyway to
improve speed (if at all possible--I'm trying to avoid Clipper incompatible
code in my dBase work). However, Clipper takes soooo long to link, and it's
no speed demon as compiler either. I love dBase's environment because it
allows you to make a change and see it very quickly. Now, if Clipper had an
environment like Turbo Pascal, I wouldn't hesititate to switch.
So, my question is this: Am I overlooking something? Is there a way to
logically divide my program as I've indicated above and still be able
to develop in dBase or do I have to use another approach? Any replies
would be very much appreciated.
--
Peter Steele, Microcomputer Applications Analyst
Acadia University, Wolfville, NS, Canada B0P1X0 (902)542-2201x121
UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!Peter
BITNET: Peter@Acadia Internet: Peter%Acadia.BITNET@CUNYVM.CUNY.EDUprime@druhi.ATT.COM (Anthony Davis) (09/14/88)
In article <1247@aucs.UUCP>, peter@aucs.UUCP (Peter Steele) writes: > I'm a fairly new dBase III+ programmer and I've run into a problem > with procedure files that I can't seem to find a straightforward way > around. Logically, my program consists of a main program, a procedure > file consisting of a set of utilities used by various other procedure > files, as well as several other procedure files each dedicated to a > particular task. My problem is that when I'm in one of the "task" > solving procedure files, I cannot access any of the utility routines > because only one procedure file can be open at a time, and I have to > call these utility routines in a variety of places (several subroutine > calls deep). The only way I can see around this problem is either (a) > put all the utility routines in each of the task procedure files; (b) > put each utility routine in its own procedure file of the same name as the > utility routine; or (c) convert to Clipper. > ......... > (c) seems to be my only solution. > This is okay because I intended to convert to Clipper at the end anyway to > improve speed (if at all possible--I'm trying to avoid Clipper incompatible > code in my dBase work). However, Clipper takes soooo long to link, and it's ^^^^^^^^^^^^^^^^^^^^ Yes, this is VERY VERY true when using PLINK to link your programs. But, Clipper supports other linkers, namely TLINK by Borland Int. Using TLINK speeds up your link time by 80%(based on empirical studies only!! 8-) ). I've found that linking with TLINK is extremely fast. > no speed demon as compiler either. ^^^^^^^^^^^^^^^^^^^^^^^ Not so! Nantucket's new release "Summer 87" has a very *intelligent* and fast compiler. It also does loop optimization and supports overlays. If you plan to purchase Clipper, I'd suggest getting the latest release. Hope this helps! #include "include/normal_disclaimer.h" Tony Davis AT&T Bell Labs, Denver Co. local: druhi!prime net: att!druhi!prime