Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
OLE Automation w/in Report Writer (Word Doc or Excel Cha
Message
From
29/06/2000 10:46:58
Jared Anderson
Marketing Support Solutions, Inc.
Forest, Virginia, United States
 
 
To
28/06/2000 12:13:39
Jared Anderson
Marketing Support Solutions, Inc.
Forest, Virginia, United States
General information
Forum:
Visual FoxPro
Category:
COM/DCOM and OLE Automation
Miscellaneous
Thread ID:
00385868
Message ID:
00386441
Views:
37
Hello again all. I hadn't gotten any replies to this, but I have 1) made a little bit of discovery/progress on my own and 2) searched some of the recent maps here on UT [which I 'shoulda done in the first place'] and found some past discussions on similar topics.

I wanted to share what I found to 1) see if anyone has any further input/suggested-preference for the options, and especially 2) have here for those who may be looking for this very thing soon, as I am now. [ESPECIALLY if for whatever reason (mainly the decisions of the-powers-that-be), they SPECIFICALLY need the FoxPro Reports, which truly comprises only one of the following suggestions.]

There seem to be three main options.

--

First, it was suggested simply to use Automation to CREATE the whole report in Word and Excel, forgoing the FoxPro Report Writer or FoxPro Programmatic Reports in general. This certainly has its advantages, but it is a sort of "sidestep" after all. And for those not proficient in making very stylish reports in word, with outlines and borders and whatever-else may want to be thrown in, this actually could add some extra work, since the design tools of FoxPro Report Writer etc. are not available. But it's a decent option.

--

Second, MANY people were shouting out "Crystal Reports". I have never worked with this, but it sounds very popular, and we probably will at least look into it. It, too, is a sort of "sidestep", but the majority (of people who have been partaking in prior discussions of this topic) seems to concur with one another that this is the way to go.

--

And third, the option I myself was trying to gather information to pursue, and the one for which I have found SOME info in the UT, is to actually insert an Excel Chart, in this case, into the FoxPro report. This can be done by either embedding the chart in the General Field of a FoxPro Table, and "inserting OLE/picture from FIELD" into the report, OR by saving the Chart as a Picture File (which can be done programmatically through Automation) and "inserting OLE/picture from FILE" into the report.

Each has its advantage, but both could require actually first having an instance of a "temporary file", which is of course something many people wish to avoid because of the potential need for drastic cleanup. The image file would definitely be such a temporary file, as would a true FoxPro Table file. PERHAPS, this could be done with a Cursor instead??? (The problem comes for updates / changes to the chart on the fly??)

Of course, this is assuming the chart already exists and is STATIC. If, as would more likely be the case, the chart is representative of something that has CHANGED or of data that is, of course, what is being reported ON, then it would have to be created DYNAMICALLY. This can be done through Excel Automation as well, drawing the data from 'whatever sources' into an instance of an Excel Workbook or Sheet, specifying Range, Style and Properties of the Chart, creating the Chart, and following either the "imbed in General Field" or the "save as Picture File" option mentioned above. For more information on Adding OLE (esp. Automation), check out MSDN's http://msdn.microsoft.com/library/devprods/vs6/vfoxpro/foxhelp/dgadding_ole.htm ... and for more information on the Excel Objects (including Range, etc), see Chapter 4 of the Microsoft Office / Visual Basic Programmer's Guide at http://msdn.microsoft.com/library/officedev/office97/web/004.htm

This is, of course, the Office97 version of this documentation. (It's Excel97 I'm looking to incorporate in my case.)

--
--

This third option certainly seems to potentially involve a lot of coding, but I'm not personally that familiar with either of the other two, and they perhaps could involve a deal of "working" as well. If anyone has explored one or more of these options and definitely has specific REASONS as to a preference for one over the other, that is especially what *I* would be interested in hearing ... b/c I sure as heck don't know for sure which route I should take :)

So ... that's what I've come up with on my own so far, including some brief suggestions from others. If anyone has any further insight/suggestions, I'd love to hear it/them ...

Thanks so much!

Jared M Anderson
Interactive Data Systems, Inc.
janderson@idevgroup.com
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform