use Win32::OLE;

#my $Word = Win32::OLE->new('Word.Application')or die "Couldn't open w
+ord";

## use the following if Word is already running
my $Word = Win32::OLE->GetActiveObject("Word.Application", \&QuitApp);


Word->Documents()->Open("c:\\Projects\\wtemplates\\TEMPLATE.DOC");
[download]

Are you sure the object got created? Also ... I'm not sure Word would like several scripts trying to automate it at once. IMHO it'd be better to skip the GetActiveObject().

And are you actually sure you HAVE to fill in a DOC? What about saving the template in RTF format and filling in the data then? Take a look at Template::RTF, maybe that's all you need. And since that would not force you to create the whole huge Word object it should be much quicker.

Jenda

I've done this before; it's definitely feasable. I seem to recall that reusing a COM object didn't work right. My code had to create a new object for each connection. I don't have the code though, not that I really want to see it again. :)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I presume it's compiled for 5.8. I use ActivePerl 5.8 and Win32::OLE comes as a part of the standard library. Also, I've tested my script from the command line and it works perfectly. I think the problem is in the fact that I try to use it from a CGI script on a IIS server. I searched for solutions to this on perlmonks and google groups. I was able to find a lot of questions, but not a lot of answers and whatever answers were there did not relate to the original question and just picked on a minor irrelevant problem in the script.

If someone implemented something like that in the past and it worked then I'm sure I'd find a solution eventually. I just need to know if it is possible theoretically, and if not, why not. And, also, I would like to be told if what I'm thinking of doing doesn't make sense or if there's another much simplier way that everybody does this.

As you've established, OLE from CGI is most certainly possible. One thing that hasn't been explored in this thread is whether it's a good idea or not.

My main experience with OLE happens to be driving Word and Excel from both CGI and ASP scripts. I have deployed production solutions that used these configurations and they most definitely worked. Having said that, I would not recommend it. This biggest problem is reliability. When you instantiate the word.application object a winword.exe process is started on the server. When you save your file and call the quit method on the application object then the process goes away. Unfortunately, in real life that doesn't always happen. For various reasons, the winword.exe process will sometimes refuse to exit and you'll end up with a stray process on the server taking up megabytes of memory and potentially holding an exclusive lock on some shared resource - forever. If a shared resource is locked, the next request will fail and another process will be left behind. Eventually, the server will crash or you will reboot it before it crashes.

Some of the issues are under your control. For example, there's a flag you can pass to the quit method that tells it to quit even if there are unsaved files open - always use that option. Also, consider what would happen if two requests hit the server at the same time. If you're using shared resources, use locking at the Perl level around the critical bits of code.

Winword.exe is first and foremost a GUI app. If it strikes some unexpected situation, its standard reaction is to pop up a dialog on the server console (eg: "File XXXXX.DOC is in use do you want to open it in read-only mode?") and wait forever. In most cases, the dialog won't be visible, so even if you happened to be at the server console you still couldn't sort it out.

Another hairy area is security. I've seen a number of scripts developed and tested under an Administrative user ID that could not be made to work under an unpriviliged user. Some level of mucking around with DCOMCNFG.EXE is often called for and that stuff is black magic.

If I'm sounding bitter it is because of the battle scars I've earned in the trenches. If you can possibly avoid it, don't go there.

Just in case someone came across this post while searching for an answer to a similar question, Microsoft Knowledge Base Article 257757 has more information on this subject.

++relax99 for the pointer to the KB article. The key phrase from the introductory paragraphs:

Microsoft does not recommend or support server-side Automation of Office.

Thank you for this post. I was wondering about the very same issues as I actually never developed something like this before. Reliability is an issue as I can not risk bringing down the production web server. I guess I would have to think about the alternative solutions. If anyone else has successfully put similar systems in use or, after considering the issues, decided to use a different approach, please feel free to post your story!