>John,
>
>I tried out FRX2Word and was pretty impressed with how well it renders a report in Word. One questions I have: I notice that the word doc uses boxes to contain the text. This looks very good, but makes it more difficult to edit the next afterwarrds. Does your next version address this issue?
>

Even if it did not, you have the source code - just get rid of the shape in your version. That's why it's released with the source code; if you need/want it modified, go to it!

>A requirement that I have from a client is that a report is easily modified by the user in word after it is created. These reports are basic simple reports with one font and a couple of font sizes/styles. One thought I had on this is that I could generate the report to an ASCII file, and include some basic formatting tags. Sort of quazi html tags. Then have some automation code open up the text file and then feed it into a word document, using the tags to set fontsize/style. Thus one would end up with a pure text file the same as if you had sat and typed it in by hand. This file could also then be saved as html if one wanted to do that.
>

This really sounds like creating an RTF document is an easy alternative, since you could embed RTF markers directly, and allow the user to edit it either with whatever the default editor for RTF files is installed by calling ShellExecute() for the file once it's been generated (if Word is installed, it'll use Word; WordPad is assigned to the .RTF extension if no other app has taken it over. If Word is installed, you have all of Word's abilities like converting to HTML), or you can work with the ActiveX RichTextBox control in a VFP form (the FFC has a class to simplify the UI for editing in a RichTextBox and adding formatting); printing is a fairly simple matter of calling ShellExecute() for the RTF file, with the 'Print' rather than 'Open' verb - you can use the VFP FFC _ShellExecute() class to do this - generally, RTF will have an Open (default), Print, and PrintTo (print, offering the user the printer selection dialog of the OLE server app; other verbs commonly offered are Edit (equivalent to Open) and New (open a new document in the startup directory).

>I am just wondering if you had ever gone done this road and have any advice on the matter.

Unless you provide a method to save the 'edited' report and then offer the saved result instead of regenerating it when the user reruns the report using the same parameters, this tends to come back to haunt you later - the user may assume that once he's edited a report generated in the app, the changes will show up in later runs, and generally, it will decrease the user's confidence in the accuracy and reliability of the app unless the edited report is saved, preferably with some sort of versioning to let you see what exactly got changed, and when. I have been bitten more than once; my classic example was an order processing app I did that let the salesman (let's call him Bob) alter the sales proposal, and Bob edits the document, offering a 10% discount if accepted before end of month in the document, without reflecting those changes in the order processing system. The client calls back, speaks to a different rep, Marty, (Bob is out to lunch), and says that he's placing the order. Marty calls up the sales order and releases it, generating a packing list and invoice that doesn't include the changes offered by Bob. Bob eventually finds out a few days later when the client's accounting department calls, extremely annoyed at not receiving the offered discount. Of course, Bob doesn't have a copy of the altered sales proposal on hand, and agrees to give them a 15% discount on the order...ad nauseum.

In the typical fulfillment business environment, I simply did not allow editing of the business documents - they can be annotated, but the document itself is a machine-controlled item. When annotation was needed, I added annoation to the appropriate tables backing the document; an invoice for example would have a preface, line item annotations, and an invoice footer, all tied to memo fields. I am willing to pay the extra 4 bytes/record and the .FPT file per applicable table. Any changes to the document are restricted to these areas, and are retained from run to run, so annotations will stick.

Many of the reports needed to be annotated, and in many cases, the document needed to ship via email or fax. In the case of management reports, I also let the user export documents, but I make sure to add a tag to the document so that we know it's an exported item that may differ from the recorded detail in our database. In theory, if an exported document is seen, it should tell the user that exported content should be checked before it's accepted. It isn't a perfect solution, but it catches the bulk of situations where some crucial detail is not recorded, and it ensures that we can safely reprint documents from the database, secure in the knowledge that the bulk of annotations are saved on the documents.

I have other clients who use a management tool to create their proposals. One of these is an aircraft freight charter business. They store the client, shipping requirements and contact information in a database, and construct route proposals to select appropriate planes, possible travel routes, and subcontracted services to handle the request. The detail is not in and of itself going to reflect all the issues which might affect the final detail; there is fixed content (origin, destination, weight, cube, cargo type are a few examples) which is saved, and there is constructed detail (eg aircraft type, routing, estimated fuel requirements, excess capacity) which are needed for every proposal, and which need to accurately reside in the database. In this type of application, I generate sales proposals as Word documents; the document saves the id of the proposal, and the proposal document names are stored in the database. The user has the option of creating new proposal documents, working with the already generated documents, or changing the data in the database and rebuilding named sections of the proposal document with updated content. For this sort of app, I rely on Word's revision history capabilities, using automation to create or update the document with changes to ensure that the historical content of changes are retained in the working document.

Contracts are obviously editable documents, which are started from boilerplate based on the database content that supported the document. Once a contract is accepted, that's the end of 'editable' business documents - accounting documents are not editable in the same fashion, for obvious reasons. Their accounting app provides for copious notation of business documents.

I'd cringe in horror if the details of business transactions were editable in a fashion that could make them differ from the business records. If it's a matter of aesthetics, I'd try to offer them a few annotation areas saved with the rest of the business data so that the information in the database reflected the actual issues.