Currently I'm working on an app that needs to interact with M$ Word. The intended users are computer noobs, so I expect no knowledge from them whatsoever.

Problem.
My app calculates/compose tabular data (in the order of 6 cols x 50 rows). These data have to be inserted into a word document as a word table. (Most users will not be able to convert text with tabs to a table in Word, no matter how often explained).

Two different approaches come to mind.

First approach:
Paste the data (all strings) onto the clipboard in Word Table format. (I can get the users to paste this in their document...) Does anyone have a clue as to how to achieve this?

Second approach:
Use MS Office automation.
Create new document from template (how do I know where user's templates (*.dot files) are?).
Go to right place in document.
Create table
Insert data into table.

There is a basic wiki document on how to open a word doc in Word with automation, but I never used office automation at all, so all steps I have no clue as to how to achieve them.

If at all possible I'd prefer the first approach.

Anyone got some suggestions or knows a good place to start looking. Mind you, I'm really just a basic-stuff programmer.

Bart

Bart ha scritto:

If the dimensions of your table are fixed, there is another method that avoids you lot af headaches: build the document you need with word, put into the cells special tags, i.e: %r01c01, %r02c01,..., an so on.

Then save the document as rtf (rich text format) so your program can read in the file, substitute the tags with your values and save it again.

Hope this can help,
bye

Better stay away from creating data structures for external applications
- this approach most probably will fail with the next Word version :-(

Even if you intend to bind your customers to updates of your program, you'll have to determine the installed Word version at runtime, and provide the code for *every* supported version.

Ask in a MS Office/Word group. Your problem is not Lazarus or Pascal related, it's a matter of the "VBA for Word" programming language and libraries.

DoDi

@tiziano

Unfortunately this requires that the enduser (te ones with the word document) somehow insert the modified RTF file in the document. That's gonna be a disaster...

@Hans-Peter

Better stay away from creating data structures for external applications - this approach most probably will fail with the next Word version :-(

That sucks (well, it is M$)

Even if you intend to bind your customers to updates of your program, you'll have to determine the installed Word version at runtime, and provide the code for *every* supported version.

That sucks even more.

Could I put a table as HTML on the clipboard? Word will interpret that as a table and happily paste it.

Bart

--- El vie 30-ene-09, Bart escribi?:

StringGrid1.CopyToClipboard;

Word->Paste and done.

Jesus Reyes A.

__________________________________________________ Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/

If your only contents in the word document is the table you can create an excel document using FPSpreadsheet:

http://wiki.lazarus.freepascal.org/FPSpreadsheet

If the format needs to be Word then you would need to paste it to word.

Ideally I imagined a full library to generate office documents could be created. But right now I only have spreadsheet support working =) And that needs polishing.

Jesus Reyes wrote

StringGrid1.CopyToClipboard; Word->Paste and done.

No sorry, it will paste as text in Word.
For me personally that is good enough, I can convert text into table in Word. The endusers will most probably not be able to remeber how to do this and find the whole procedure to cumbersome.
The app is intended to make filling in the Word Table (creating and calculating codes from timedifferences), so super ease of use is a must.

(Also .CopyToClipBoard copies to much cells in my case, but that's trivial)

Bart

--- El vie 30-ene-09, Bart escribi?:

Is not Word programmable?, put a button somewhere there and convert the text into a table, then make sure they know how to click a button (btw, I don't think users are that stupid).

Jesus Reyes A.

__________________________________________________ Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/

Automation has nothing to do with VBA. That's the whole point of Automation, that it's language independent.

As Felipe rightly points out, many Laz users could profit from a library for creating office documents. Ideally it would have 3 notable characteristics:

(1) Can create any type of office document programmatically without a particular office app or version being present. For word processing documents, RTF is perfect since it's a text format that is well supported by all word processors. FPC includes a unit for working with RTF documents. I created a thin wrapper for it that allows you to create RTF documents:

http://wiki.lazarus.freepascal.org/XDev_Toolkit

(2) Can manipulate the resulting RTF file with the office app. On Windows, Automation works great for that purpose. Your only real challenges here are: (a) Figuring out a way to mark the place in the document where the table should be inserted. You can do this in a number of ways, for example if your app or your users create documents based on a template that you provide, you could insert a hidden bookmark in the template and look for this in the document's Fields collection via Automation. (b) FPC 2.2.2 does not fully support Automation yet, it appears.

You can insert text into a Word document from the clipboard via Automation with something like this:

worddoc.ActiveWindow.Selection.Paste;

To insert an RTF file into the document:

worddoc.ActiveWindow.Selection.InsertFile(rtffilename,
ConfirmConversions:=False);

(3) Can do (2) across a variety of word processors in a cross- platform, cross-app way. This includes Word, OO and Apple's Pages. On Windows you can use Automation to manipulate both Word and OO. On OS X you can use AppleScript to manipulate word processors that include a dictionary of classes:

http://wiki.lazarus.freepascal.org/
Multiplatform_Programming_Guide#Making_do_without_Windows_COM_Automation

Thanks.

-Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090130/ea80f1bb/attachment.html

I agree with Phil. Automation is completely independent of the language.

There are currently three solutions to do what you want, in FPC/Lazarus. a - wait for the next full version of FPC. Automation is scheduled to be included. COM is already available.
b - based on the COM layer, build a Word Interface unit to insert your data into the word tables.
c - use Excel as an intermediate. Generate your tables there, and ask your user or do a little VB code to load the Excel tables into the Word document.

As a help, I am doing a port of Excel Automation of which a <very> preliminary version is available here:
http://tcoq.free.fr/composants.html.
It uses the COM layer to provide an easier access to Excel Automation, from FPC/Lazarus.
You can use it either as an example to do the b) option, or as a means to do c) option.

Good luck,
Thierry

Thanks all for your suggestions, I'll look int it.

Bart

Bart,

If you want to see some info on how this sort of Automation document manipulation is used with actual production software, grab the SmartDoc.doc document that's pointed to by the Creating a 'Smart' Document link on this page:

http://www.agry.purdue.edu/mmp/MmpDocs.htm

This document covers template and field basics. Note that a template file (.dot) can go anywhere, for example in the same folder as your app. If you want your users to select your template in Word's File | New, then it should go somewhere that Word can find it, like under C: \Program Files\Microsoft Office\Templates\1033. If you're creating a document programmatically, it doesn't have to go there, though.

Thanks.

-Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090131/250fbf14/attachment.html