Substitute for MSWord Office Automation 2

[Bryan - Gendev]

In my app I use an MSWord object to build a report in MSWord.

loWord = CREATEOBJECT("word.application")
loDoc = loWord.documents.ADD()

I have some users that have look-alike Word Processors like Libre or Open Office that open MSWord Reports and want an MSWord compatible report from my application.

Is it possible to produce this with native VFP or is a third party control the only way?

Regards

GenDev

 

[Olaf Doschke]

There are COM support libraries for Open Office, but you have to restart automating Open Office from scratch, you can't reuse code you did for MS Word. See

http://www.openoffice.org/udk/common/man/tutorial/office_automation.html

That said I have done absolutely nothing with Open Office Automation, and haven't found much in regard of using that. For example here you have thread184-1514000, but I doubt it's a good starter, too specific.
Maybe this would help:

http://fox.wikis.com/wc.dll?Wiki~OpenOffice

Don't expect more than pointers from me, perhaps others have experience with that and can share it.

Bye, Olaf.

 

[Mike Lewis]

Do the Libre and Open Office users also have Microsoft Word installed? I'm wondering if your company has installed Word or Microsoft Office on all computers as a matter of policy, even though some users never use it.

If so, then you can continue to use Word Automation to produce the documents, but let the users open the documents interactively in their preferred application. My understanding is that Libre and Open Office can read Word DOC files (but maybe not DOCX). So the users don't really need to be aware of how you are creating the docs.

You can, of course, also create the docs programmatically in Word, and then use ShellExecute() to open them in the user's preferred application, so that the user can view the doc and perhaps edit it.

I realise all this is probably obvious, but I thought I'd mention it just in case it's useful.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nigel Gomm]

one other option is to create the report using the VFP report writer and then use XFRX to export to word, open office, rtf etc as the user requires.

see

http://www.eqeus.com/frx2wrd.php

hth

nigel

 

[Bryan - Gendev]

Mike,

My users are home genealogists that have to purchase their own software - that is why they are keen on OO, Libre etc.

GenDev

 

[Bryan - Gendev]

Nigel,

eques's XFRX product looks good but I can't justify the up front cost. I'mm hoping there is a VFP solution.

GenDev

 

[Mike Lewis]

So, you've got no control over the software the user has installed, and you can't justify purchasing XFRX.

In that case, you have only two options:

1. Extend your application so that it supports all three word processors (Word, Libre and Open Office). For Word and Open Office, you would do that via Automation - but you would have to write a different set of code for each of the two. I don't know anything about controlling Libre programmatically, or even if it's possible. If no-one else here knows, you could try asking in a Libre developers forum.

2. Only offer support for Word. In your marketing, state clearly that a pre-requisite for producing reports in your application is to have Word installed.

Personally, I would go down the XFRX route, but as that's not possible in this case, I can't see any other options.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nigel Gomm]

try

http://foxypreviewer.codeplex.com/

and export to RTF. a shellexecute on the RTF file should then open it up in whatever the user has installed (wordpad even).

n

 

[Bryan - Gendev]

Mike,

Just to clarify, I would amend your statement 2

your statement 1 - the effort for only a small number of users isn't worth it.

your statement 2

a pre-requisite for producing PRINTED reports in the xxxxxx application is to have Word installed. However a PDF printer driver will produce printed reports from the Preview screen of each report if chosen.

GenDEv

 

[Bryan - Gendev]

Nigel,

Thanks for that heads-up. I will investigate further...

GenDev

 

[Olaf Doschke]

Well,

if you create reports by word automation, you can't replace that with FRX2ANY or FoxyPreviwer, as those only address FRX reports.

It's not straight forward to replace all the possibilities you have to automate Word, including for example to use VBA makros etc. into a foxpro report.

The only thing this kind of reporting has in common is the final document type.

That said it is easier to change the final output type of FRX reports from directly printing to paper via a printer to PDF or other formats, but first you need to redo your reports with the foxpro report designer, and that can also be much of an overhead in comparison to OLE automation of word.

For example I do assemble a letter in word, which is composed from several very different sections, includes word tables and header/footer. It wouldn't be impossible to redo as FRX, as we have header/footer bands, multiple bands, etc. But just at the word tables that would need to change to something different, eg an ole control.

It may be less effort than redoing automation to Open Office or LibreOffice, but it's a totally different approach than automation and more rigid than what automation can do. There are things, which are far easier done with an FRX, as a list of data, but other stuff is easier done via automation of word. Mail merge is for example the other way around, printing a "report" (doc) for each record. But that's not even the hardest thing to redo as an FRX instead, as you can SCAN a table and REPORT FORM... NEXT 1 only to create a series of reports each from one record. The harder stuff not fitting into FRXes is very individual automation of document pages, jumping from here to there and embedding things into word.

So I wouldn't recommend something like FRX2ANY or FokyPreviewer or FRXes at all, before I knew the layout and code done for dox(x) generation, as it is now. It's normally not straight forward to do in FRX, which mostly is a reason to go for word automation in the first place.

Bye, Olaf.

 

[Mike Lewis]

a pre-requisite for producing PRINTED reports in the xxxxxx application is to have Word installed. However a PDF printer driver will produce printed reports from the Preview screen of each report if chosen.

That's not what I understood.

You originally said that you were using Word Automation to build the report, not just to print it. If you were using the native VFP report tools to build the report, then you would also use those tools to print it, so there would be no issue. I understood you wanted to build the report in Word so that the user could subsequently edit it as a word processor document. In that case, either the user would need to have Word installed, or you would have to use some other method of producing the report as a Word document.

Either way, using a PDF printer driver is not an alternative to that.

I also think that your above statement would be somewhat confusing to the average end-user. First you way that you need Word installed to print a report. Then you say, actually you don't need Word installed because you can use a PDF driver. Which is it?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Bryan - Gendev]

Mike,

As I showed above, In my app I use an MSWord object to build a report in MSWord to allow a user to get a file which can be printed or edited. I also provide the same format report via a VFP frx report - thiss can be printed to a file with a PDF driver if they want to save actual paper.

They are just options to allow them to create a catalogue of exhibits from their genealogy program. The largest catalogue I have seen is over 2000 pages.The OO or Libre users cannot get any permanent record in catalogue report form onto their hard drives which is what I was really wanting to say when the thread started. My apologies for being obtuse.

GenDev

 

[Olaf Doschke]

Well, if the word doc generation merely clones what the FRX does, you can use FoxyPreviewer, as Nigel suggest.

Then you can just pension your word automation code and simply execute the FRX via Foxypreviewer, which cannot only save a report into PDF, but also RTF. RTF can be read by word, and I assume Open Office can also read it. At least the free Wordpad can read it, too and from there you can at least copy&paste it into other office products, if they can't import RTF.

From what I googled more recent versions of OpenOffice or LibreOffice have an import filter or can open RTF in some other way.

Bye, Olaf.

 

[craigber]

IMO, extending what you have is a short term fix. As more and more applications move to 64 bit, you'll continue to have issues. Office is already there.

Third party options are your best choice.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Bryan - Gendev]

I am excited by FoxyPreviewer. I am using it on my 64bit WIN 8 development PC.

I have sent sample reports to my OO user to test the rtf. I originally had hand coded HTML reports but had a few bad reports - now I can offer all sorts as Olaf mentions.

FoxyPreviewer is a great control and I shall be making a contribution.

I finally got what I had hoped for when I started the thread.

Thanks everybody

GenDev

 

[Olaf Doschke]

Good luck. RTF is not ideal for your non MS Office users, but if it works out and RTF covers all your report features of text formatting, it's a compromise. One downside is, as far as I know RTF does not spport embedded (ole) objects, so if your reports may be enhanced with ActiveX you're thrown at the problem of not being able to export to some usable exchange format again.

XFRX may still be worth a try, as it also covers DOC, and it's a one time investment you may use more often, the usage for your customers is royalty free, so it's up to you to decide how you split your one time cost across your products and customers.

Bye, Olaf.