I am trying to create a graph(s) that will do two things:
1. by date from 1/1/60 to the present, graph about 12 items. The Y axis would 
be a percent and the X would be the number. When I do it, instead of getting 
one date per graph and then move downward, I get on the screen, 3 days per 
graph but when I view the graph, I get about 4 months.
2. by date, I want to do the above but get a moving average instead of the 
actual number.
Should I do my graphing in Quattro and then OLE it back to Paradox 5.0? or 
should I do it in Paradox?
Thanks
===
 * QMPro 1.53 * Now Dan...spell Potato...s-p-u-d
--- TosScan 1.00
1:226/120)
---------------
** A related thread FOLLOWS this message.

FIDO MESSAGE AREA==> TOPIC: 119 PARADOX       Ref: BE^C0767 Date: 10/31/94
From: MARK POTOCHNIK                                        Time: 08:12am
\/To: DAVID SHERMAN                                       (Read 14 times)
Subj: R: Paradox graphs

DS> Should I do my graphing in Quattro and then OLE it back to Paradox
5.0? or should I do it in Paradox?
 
Do it in the one that makes the best graphs. Check out the new Quattro 6.0
really nice...
\|\_|\__/|  |
/||_| \/ |/\|
---------------
>>>>>>>>>>>>>>>>>>>>>> LAST Message In Thread <<<<<<<<<<<<<<<<<<<<<<

FIDO MESSAGE AREA==> TOPIC: 119 PARADOX       Ref: BE^00002 Date: 10/28/94
From: LANCE LEONARD                                         Time: 10:42am
\/To: JP BICKET                                           (Read 14 times)
Subj: ObjectPAL  Books

JP,
JB> Writing style be damned, when tackling a problem I go to Prestwood's 
JB> book first.  It's certainly more comprehensable than the manuals which 
JB> *also* have a tendency to repeat the same cryptic explainations two or 
JB> more times -- at least I understand Mike when he repeats himself).  
I'll admit that Mike's book is more readable than the manuals, but (to be 
fair to the manuals' writers), Mike didn't have a very string page count 
constraint.  The writers of the manuals are often told that they cannot go 
over a certain page count (for cost reasons).  This isn't a problem limited 
solely to BI's documentation teams, it's rife throughout the industry where 
many of these decisions are made by uppser managers who are two or three 
levels removed from the product and simply don't have the time to understand 
the products that they're determining the pages for.  I'm sure if the 
decision had to have been made by someone a little more experienced in the 
product, we would have larger manuals and explanations that take more time to 
develop their points.
 
JB> I also have "Programming Paradox 4.5 for Windows" (Jensen and Anderson) 
JB> which at times has been useful, and at times has not.  
This is, I think, par for third-party books.  Usually, I'm happy with my 
investment if I learn three major techniques or can develop three major 
techniques from the material in the book.  That's roughly $15 per trick and 
seems a good tradeoff for the expense and hassle of calling TS.  
 
For the most part, Cary's materials (his event model discussions, as you 
pointed out) are excellent and I think they provide a lot of groundwork for 
folks who are just getting started with development period.  Groundwork that 
can be exploited by other books.
 
My major problem with Mike's book is that he wrote a very good book for PFW 
1.0.  But, the techniques he discusses are not necessarily the best ones for 
4.5 or 5.0.  In the later releases, a lot of holes have been filled.  Now, to 
be fair, this isn't Mike's fault--it's his publisher's fault for trying to 
foist old material on the unsuspecting public.
 
While some of the techniques were the only way to accomplish the result in 
1.0,they can lead to less than optimal performance in the latest versions.  
That's my only real beef.
JB> ...that I will cancel it immediately if they allow Mr. 
JB> Coffey to run amok unmuzzled again in the book review section.  That hit 
JB> piece read more like taking personal shots against an author he doesn't 
JB> like than a helpful editorial on the merits of the book as a developer 
I can see that viewpoint, but I'm not sure I agree with it completely, for 
two reasons.  First, having written a few reviews for PI, I know how tough it 
is to try to see whether something is suitable for recommendation or not.  If 
you don't like it, you have to weight whether or not others will like it or 
be able to use it.  Clearly, Jerry had some of concerns about the suitability 
of the material for 4.5.  The second reason I need to disagree ever so 
slightly stems from the basics of teaching.  While good information is 
mandatory, a good presentation contributes just as much to the sucess of the 
learning process.  For example, to learn a programming language (or 
development environment), you need to be able to understand the way that 
environment works and design your materials so they consistently reinforce 
and express your take on that environment.
For Paradox (and databases), this is especially true.  An edition of PBE 
contained an anecdote who's punchline was "Paradox isn't hard, databases are 
hard."  With PFW (and the fact that you're also learning Windows development 
concepts and OOP development concepts, the need to present a consistent 
argument is even more important, for you're taking the novice developer 
through up to four new thought processes: database issues, language/product 
issues, Windows dev issues, and OOP concepts.  (The best OPAL apps combine 
the strengths of all four concepts.)
 
I think that's where many of the concerns came from.  I don't think it was 
personal at all.  And I certainly don't think it was personally motivated.  
After all, Tech Editors are paid in lump sums and do not receive royalties 
(same for contrubting authors.)  Only named authors get royalties.  (I know 
Jerry and he's far too professional for that.  If he (or Mitch) was like 
that, I wouldn't have written more than one piece for them.
Jerry and I talked about the review afterward and he mentioned how hard it 
was,but also pointed out that he felt a responsibility to the readers to let 
them know his feelings about the material.  The key here, I think, is to 
remember that reviewers are only giving their opinion.  If everything was 
"good and helpful" and all the reviews looked the same, then we'd have 
nothing useful.  Whether we agree with strong reviews or not, you'll have to 
admit that it did force you to consider the matter for yourself.
 
I wouldn't cancel your subscription if there's another review you disagree 
with, but I will suggest the same thing that I did to Mike--write a letter to 
the editor, take advantage of the forum available.  If it's intelligentlly 
and professionally written (and fits into the schedule), then I know it'll 
get published.  (PI strives to be a very professional, balanced 
magazine--which is why I like it.)  That way, you can provide your opinion 
and then let the market decide.  (Actually, Jerry would probably suggest 
writing a comparison of existing OPAL books.  )
 
Bear in mind that the fact that I don't completely agree with you on this 
doesn't take away from the validity of your, my, or others' opinions.  
They're just different.  That's all.
 
Hope this helps...
 -- Lance  
--- Maximus 2.01wb
---------------
** A related thread FOLLOWS this message.

FIDO MESSAGE AREA==> TOPIC: 119 PARADOX       Ref: BE^D2162 Date: 10/31/94
From: STEVE BOOTH                                           Time: 09:36am
\/To: LANCE LEONARD                                       (Read 13 times)
Subj: R: ObjectPAL  Books

Lance,
   Thank you for the explanation of your feelings about Prestwood's book.
It really helped me understand where you and the reviewer were coming from
... that's one of the problems with the written word... it's just so
difficult to see the underlying motivations. I still disagree with you
regarding the book, but at least now I know why you think that way.
 
    Thanks again.
 
Regards, STeve... (Exec-PC Netmail: 1:154/280)
---------------
>>>>>>>>>>>>>>>>>>>>>> LAST Message In Thread <<<<<<<<<<<<<<<<<<<<<<

FIDO MESSAGE AREA==> TOPIC: 119 PARADOX       Ref: BE^00003 Date: 10/28/94
From: LANCE LEONARD                                         Time: 11:11am
\/To: AL HARRISON                                         (Read 13 times)
Subj: DOS -VS- WINDOWS

Al,
 
AH> I would generalize the remarks by saying the difference between PDOX DOS 
AH> and WIN is that the intuitive operation that permeated 
AH> DOS version has been sacrificed or been rendered 
AH> subservient to the object-oriented flavor -- not quite 
When I first starting PFW, I would have agreed with you 100%.  I went through 
a particularly painful migration process as I learned how PFW "thinks" 
(which, as you accurately noted, is very different from PXD).  Even in 5.0, 
there are operations that seem unneccesarily difficult (though I can 
accomplish them without too much hassle.
 
But, let's remember that some of these operations are inherently more 
difficult because Windows makes them that way, not Paradox.  For example, 
printing to a file.  That's easy in a character based operating system 
because you simply open the file and dump the sequence of characters.  But, 
in the propertional spaced, typeset environment of Windows, it's not that 
easy.  You'veen this in the reverse when importing text files into a Windows 
word processor.  Your upper ASCII characters get mangled (in MS Word, not 
WP), your line spacing is difficult, you have to manually strip the trailing 
carriage returns/line feed sequences and so forth.  All just to print a 
simple text file that can be read easily.
Additionally, there are some things that were really hard in the DOS product 
that are a snap in the Windows product.  Thinks like designing forms and 
reports, things like rich data model support (ever try to implement the 
customer, orders, and lineitem data model in PXDOS?  Ick!), and so on.  There 
are a lot of things in PXDOS that are getting a little long in tooth, you'll 
have to admit.
So, BI made a choice to support Windows more than PXD in PFW.  The places 
where we have to learn new things generally stem from a) Windows uses 
techniques that are different or b) Windows programming techniques that are 
different.  It takes time to learn these, but once you've got them, the 
richness and strength of PFW really makes is far easier to accomplish 
intermediate or complex database tasks.
Yes, certain atomic operations are more difficult (like printing a file), but 
overall, it's an eaiser to use product.
 
Just my two cents...
 
-- Lance   
--- Maximus 2.01wb
---------------