Re: Graphing in VFP? Help? Example in post...

All of this can be automated. (The technique is called, oddly enough,
automation. <g>)

To automate your work with Excel...

oXL = Createobject("Excel.application")
oXL.Sheets.Add()
oXL.Visible = .t.

etc.

If you're actually using Acrobat, I'm not 100% sure but I'm fairly sure it's
a capable automation server. And if you're not using Acrobat, there are a
plethora of PDF tools on the market. We use the Amyuni suite, particularly
for appending multiple PDF's together.

None of this entire process should be manual.

Dan


43fan wrote:
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:%23fCnYXpfGHA.2032@xxxxxxxxxxxxxxxxxxxxxxx
43fan wrote:
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:%23137IHofGHA.4864@xxxxxxxxxxxxxxxxxxxxxxx
Um, no ... you're NOT trying to create the graph "completely in
VFP". You're
still using an external program (MS Graph) and my guess is your
result is because you don't have it installed. <s>

Why do you want to nuke a successful graphing capability? <g>

General fields, which are generally <g> to be avoided, are not
"completely within VFP" -- they hold blobs of data that belong to
an external program. VFP doesn't know a dang thing about what's in
'em, how to display 'em, or anything else about 'em. When a
general field is encountered, VFP reaches out into the Windows
ooze to whoever owns that data and says "display this!". That's
the extent of the control VFP (or you) have over a general field.

I'd stick with Excel if I were you.

My problem with sticking to Excel is, these graphs are all part of a
final report that is to be sent to customers. The end result would
be placed in a single PDF file, along with several reports that are
run within VFP.

I'm glad I asked that question then. This is a horse of an ENTIRELY
different color!

Yes, you do need a general field if you're printing the graph in a
report. Or why don't you print to a PDF "printer" from Excel
directly and merge the
resulting PDF with the one you create from VFP?


I do that now... I print everything I can in VFP, directly to PDF
using FRX2ANY. Then I create the graphs I need in Excel, and then
append them into the previously created PDF. Thing is, I want it all
automated at some point, no putting the manual together manually. We
may have as many as say 7 sets of tires on 7 different vehicles
running on a single test. I have it to the point(printing anyway,
sending it to PDF is turning out to be an entirely different animal
in this matter) of being able to print the tire reports for all seven
sets, just by entering the main code that links them all together.
As I said, getting them to PDF this way is turning out to be an
animal, as it appears I need to use the reportlistener and also
FRX2ANY's report listener, and I have no idea what I'm doing
there(very little idea anywhere else!*g*)

IF I can get the report listener stuff working, and then I can also
add in the graphs printing through VFP, then someone who just knows
the main code number that connects an entire test together, can
actually run the final report. Enter a few numbers, click a few
buttons(at most) and voila, it's done, all in PDF, ready to send.
If I have to do it through Excel and VFP, then use Acrobat to combine
them, then someone has to be trained how to do all of that.

You skipped over the "Which tool should I use?" question and went
right for
"How do I use this hammer?" when you might actually need a
screwdriver. <g>

That could be, but I dunno, for this project, I think I DO need a
hammer. ;)



Dan


.

Loading