OIPI's INIT message has a "Load RTF parameter" that is used to specify a RTF file that is opened and displayed in the report. What exactly is this for? To display and print static documents?

The reason this caught my attention is my new app's need for reporting capabilities. I think it can be used for printing dynamic data as well, and I'd like some feedback on my idea for this.

But first - what is a report format really, and what is reporting?

A report format can be thought of as - and I believe in real systems often is - a template, i.e, a "document" that may contain headers and footers and label texts and logos and other static features, and most important, some kind of slots where user data can be inserted, be they dates or numbers or strings or pictures or what.

Reporting is the process of combining a sequence of records with the template. For each record, a new copy of the template is added, with the record's field values inserted in the appropriate slots, and the total result printed or displayed.

My idea is to make report formats or templates with MS Word and have them stored as RTF files. Then the reporting program can make a report as a new RTF file from n copies of the template RTF (disregarding their header) with user data inserted in their slots. Finally it can use OIPI to read this new, long RTF file and print it out.

So what are your thoughts about this approach?

- Oystein -

Ummm nice idea - BUT

If you are using Word to create the templates in the first place why not use all the power built into merging data in Word itself instead of trying to manipulate an rtf file (which I think might be quite difficult with OIPI).

We use OI report definitions and OI Word header definitions to export the data that word needs when the user requests a report. Then we call a Word template with one DDE command, which then takes over with an AutoOpen macro. Then we use VBA to create the document (or multiple documents) — (or indeed compound documents - that is one document from many templates) and we deliver back to OI statistics and errors etc…

But are you trying to make this more generic? That is are you trying to get away from using Word?

Bob Watson

Bob,

If you are using Word to create the templates in the first place why not use all the power built into merging data in Word itself

Thanks for taking an interest!

Again. Searching old postings I see this is your second try at getting me to see the light.

instead of trying to manipulate an rtf file (which I think might be quite difficult with OIPI).

I need to parse my report format RTF documents into heading-like stuff and main body stuff. I don't believe this can be very difficult. With main body stuff I mean the part which is duplicated and merged with user data.

Also - before user data are inserted, some characters data must be RTF encoded. But that's easy.

Also the pieces (a heading and the body times n) must be properly put together. But that can't be too difficult either.

Note that all the manipulation of RTF data that OIPI has to do is to read, preview and print the finished result - an RTF file. Which the docs claim it can do with a proper INIT.

We use OI report definitions and OI Word header definitions to export the data that word needs when the user requests a report. Then we call a Word template with one DDE command, which then takes over with an AutoOpen macro. Then we use VBA to create the document (or multiple documents) — (or indeed compound documents - that is one document from many templates) and we deliver back to OI statistics and errors etc…

What you've got seems pretty advanced. If I decided to go for Word/merge, I'd aim for something simpler initially. Does this crude version qualify?:

- Write user data to a text file

- Start Word and tell it to open the relevant template (a dot file)

- Tell Word to merge with data from the text file

- Make Word the active program so the user can preview the result

- Leave it to the user to print out, after he's previewed the result

- Leave it to the user to close Word and/or return to the app.

Now for one very important question: What do you do with multi-valued data, AMVs in particular?

But are you trying to make this more generic?

I don't think so.

That is are you trying to get away from using Word?

I would like to avoid having to use yet another program. My app has already got a couple of extra programs - an image viewer and a thumbnail utility. In my experience every additional program means potential problems and extra work. Every new program must be installed, maintained, set up and mastered. Every new program adds to the need for user support.

With my approach only me and a few power users would use Word to create report format templates, as normal doc files, with some special but visible codes. With your approach everybody's got to have a suitable version of Word on their system.

Now everybody's got Word these days, so it needn't be bought and installed.

But is the mail merge functionality part of Word's core functionality? I noticed with the Office 2000 programs there is no end to additional stuff that might have to be installed later.

- Oystein -

Oystein,

But is the mail merge functionality part of Word's core functionality? I noticed with the Office 2000 programs there is no end to additional stuff that might have to be installed later.

Yes, it absolutely is part of the core functionality. I have been automating Word mail merge solutions through other Office applications and custom VB apps since Word '95.

The object model is very open, and it's not that difficult to do. You can either use macros as suggested by Bob, or my favored approach is to manipulate the object model through code. Of course, I do this through VB and not Arev or OI.

HTH,

[email protected]

Go Greyhound, and leave the driving to us.

Bob, Matt,

I'd like to know a bit more about your solutions. Now it's a bit hazy. I believe a brief reply to each of these two questions would clear the fog sufficiently:

- How/where do you handle multivalues?

- How do you handle page breaks (if you feel this question is relevant at all)?

- Oystein -

Today's listening suggestion: Rennie Pilgrem: Selected Werks (TCR)

Oystein

] ETC…

This approach seems reasonable if you wanted to produce fairly straight forward reports ? it might just work! However we wanted to be able to use all the power that Word provides for complex formatting. For example - different headers/footers between the first page and other pages and between sections, alternating portrait/landscape sections and complex tables. The requirements here were to produce long documents based on various data. They wouldn?t be defined as reports. They are usually mailed and may contain sections that the recipient needs to fill out and mail back. I use OIPI, Slist and ReportWriter for column type reports.

]

That would be the basic approach. In our case we always open the same template. It contains all the code to produce the document(s).

]

If we wish to display a table of related data in the report a grid(s) can be defined on our header definition form in OI. The user chooses dictionary items that he wishes to include in the Word table. This data is exported to separate text file when the document is requested along with all the other standard data from the OI table. At the appropriate place within the document (.DOT) Database merge fields are inserted which grab the data from the text fields and place it in a table.

If we have multiple documents to produce from a multivalued list (eg. A list of people all of whom need to sent a letter) , our report function parses this data and sends it to the vba macros which then handle the production of the documents (either into separate documents or to the same document).

You said it ] so it?s not really like other apps that have to installed.

As Matt said, the mail merge functionality is part of Word's core functionality. What is more there is nothing you cannot do as far as the manipulation and presentation of data form VBA goes.

This said, if all you want to do is produce reports then the RTF approach to standardisation might very well be the way to go.

If you wanted to see screen dumps or code examples of the stuff we are doing let me know.

Bob Watson

Oystein,

As far as multi-values go, in my experience I have always handled "on the fly" normalization in the code for the export. This way I don't have to deal with it in Word. Another option, I think, is to have a main document and a sub-document. Export to files, one with the non-repeating data and one with the repeating data. Have the main document merge off of the first file, and the second merge off of the second file. I have never tried this, but I am pretty sure it is possible.

As for page breaks, I let Word handle that. There are options that you can set that handle where page breaks occur. If it is a true mail-merge, where you have a template and you are merging data, Word will force a page break (by default) with each new record.

[email protected]

Go Greyhound, and leave the driving to us.

Bob, Matt,

Your latest postings explained a lot. Thank you very much.

I do think my idea is viable. At least for fairly simple reports. So I think I could get some basic reporting capabilities up and running fairly quick.

Then I could extend the reporting capabilities with other kinds of reports. Like Bob says he does columnar reports with S/List, etc.

Or I could develop my own idea further, if possible.

Of course I should do some experiments before I make a final decision.

About (A)MVs: I think we agree that in a Word document the natural way of showing multivalued data is to have them in Word tables. A template for data with a mix of single fields and an AMV could have a table with one row for the AMV. Then some programming would have to dynamically expand the number of rows to fit the data.

Matt - you suggested having a separate template document for the AMV - a document containing RTF for one table row, as I see it.

But splitting up the template could make it more difficult to create templates. It would be nice if my clients could create their own templates, and do so without much training and support.

So if possible I will have just one template document for each format, and some programming able to recognize the AMVs in the template and expand them to fit the number of values in the data. Of course it's easier if there is a separate AMV template, but it can't be too difficult to do it my way either. I could have a couple of extra codes in the template to guide the program.

About page breaks: I browsed the help texts and see there are lots of possiblities for controlling page breaks in Word. I assume I can even get my clients to master some of it.

Again - lots of thanks to both of you!

- Oystein -

View this thread on the forum...