Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!welch.jhu.edu!glenn
From: glenn@welch.jhu.edu (Glenn M. Mason)
Newsgroups: comp.databases
Subject: Re: What is missing in Paradox 3.5
Message-ID: <1991Apr18.152600.5232@welch.jhu.edu>
Date: 18 Apr 91 15:26:00 GMT
References: <9104180445.AA01554@cwns4.INS.CWRU.Edu>
Reply-To: glenn@welchlab.welch.jhu.edu (Glenn M. Mason)
Organization: Welch Medical Library, Baltimore
Lines: 101

In article <9104180445.AA01554@cwns4.INS.CWRU.Edu> aa640@cleveland.Freenet.Edu writes:
>
>Newsgroups: comp.databases
>Subject: Re: What is missing in Paradox 3.5
> 
>glenn@welch.jhu.edu (Glenn M. Mason) says:
> 
>>How about a source generator for forms, reports and tables that will
>document
>>database structures and provide means for recreating damaged or lost
>files?
> 
>You can document your database structures by using the Tools/Info option
>on
>the menu.  That creates a "structure" table.  Then you use the
>Report/Output
>function to copy the structure table to an ASCII file.

This wouldn't do a fraction of what I'd be interested in seeing. This does
provide some documentation for table structures, but most of the tedious work
is in the reports and forms. I would like to see an option that produces *real*
PAL code that would recreate a form, report or table at any time. Such a script
would have been produced simply by selecting a table, form or report and an
appropriate Paradox option to perform the action. This is the ultimate level of
documentation and backup-recovery for *all* objects generated from within the
Paradox development environment that are output in a binary format.

>Write each module of your application as a separate script, and then use
>Personal Programmer to generate the menus.  It will also generate full
>documentation of the menu hierarchy and all files used.
> 
>As for recovering damaged files, there is something called a "TUtility"
>which
>claims to be able to do that.  Happily, I have not had any occasion to
>test
>that claim.

Yes this utility has proved useful to me, but only rebuilds damaged indexes.
It would not be very useful in a situation where a table has been damaged
due to a power loss of some sort during a critical table update or other types
of PC or DOS related occurrances such as disk crashes.

>>How about a compiler?
> 
>That would be nice.  But the "procedure library" is the next best thing.
>Store all your source code in the form of procedures, write it into
>libraries,
>and load it with the "autolib" function.

Yes it is the next best thing, and the built in memory management really
makes it a useful implementation, but ... it simply can never compare to the
raw execution speed of a DOS executable. Borland certainly would be the right
company to produce a good compiler for Paradox since they have some of the
leading PC-based compiler technology; and I wouldn't be suprised to see them
come out with a compiler that has overlay management capabilities since their
other compiler products have this available. I see that PAL compilers are
beginning to pop up now - TSR Systems is marketing PalCom which would provide
what I would look for in a compiler (it does have some limitations though), but
at a price tag of ~1500. I can't justify buying it for a product that I paid
$134. for!-) You can bet that Borland will release a future version of Paradox
with a compiler that will probably be unmatched by any competition for a price
that everyone can afford.

>BTW, I was just reading a comparative review of Paradox 3.5 and other
>DBMS's
>in PC World.  Paradox Runtime costs $49.95.  The competitors who offer
>runtime
>code charge not less than five hundred bucks.

Yes I am currently using this. It is actually a version of Paradox that is
exactly the same except that the ECHO function has been disabled. It's easy to
see why they wouldn't include that function in the runtime module. So you can
expect that exact same performance from an application using Runtime that you
would under Paradox itself.

>>How about more high level application functions like pop-up dialogs and
>>menus, pull-down menu systems, etc.?
> 
>I guess you haven't tried the Data Entry Toolkit.  Just store the
>procedures
>in POPUP.SC in a library, and call SetPopUp and PopUp in your
>application.  It
>is quick and easy.

I have used the Data Entry toolkit extensively ... enough to have had to rewrite
some of the code to suit my personal tastes. The PopUp2 function, for example,
has the limitation of not allowing flexible color attribute specs (they are
read from the current attribute settings table). There are other minor things
that I have changed as well ... but I am happy at least that the source for
these critters was included so that I *could* hack them. As for the high-level
functions, I have created a library full of these things, but it was tedious
work and there are other functions that I would like to have but have not had
the time to genericize from my current applications. I think that Borland could
supply the PAL source code to build a Paradox library of many of these things
that are very general to fit a wide variety of application needs.

I think many of these things would justify a quick purchase of the next
Paradox release. I also found out that Borland is showing off its Windows-based
version of Paradox ... can't wait to see that.

Glenn