nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Manipulate Word Document

infoForDj

Hi,

One of our requirements is as follows:
1.User selects DCR
2.Clicks actions--->spell check
3.dcr is run though a cgi that converts it to .doc and launches it in a split screen format with the dcr on the left and the newly created .doc using MS Doc on the right.
****cgi should strip out html tags.
4.User would manually make changes to dcr based on spell check performed on the .doc (using MS doc functionality)
5. User can save changes

Can someone help me find documentation to use perl to convert XML into word documents and vice versa and how to manipulate word documents.

Thanks in advance,
Dhruv

Find more posts tagged with

Comments

Migrateduser

You may be interested in Win32::Word::Writer or one of the related modules:

http://search.cpan.org/~johanl/Win32-Word-Writer-0.02/lib/Win32/Word/Writer.pm

I haven't needed to work with this but it seems promising.

Adam Stoller

Hi,

One of our requirements is as follows:
1.User selects DCR
2.Clicks actions--->spell check
3.dcr is run though a cgi that converts it to .doc and launches it in a split screen format with the dcr on the left and the newly created .doc using MS Doc on the right.
****cgi should strip out html tags.
4.User would manually make changes to dcr based on spell check performed on the .doc (using MS doc functionality)
5. User can save changes

Can someone help me find documentation to use perl to convert XML into word documents and vice versa and how to manipulate word documents.

Thanks in advance,
Dhruv

Perhaps I'm overly pessimistic this morning - but I think you're doomed if you think you're going to fulfill this requirement.

The best I can think of off-hand would be to have a CGI that goes through and performs a spell-check on each individual field's contents and if it finds errors displays the text to the user in a manner that is understood (if you strip out all HTML tags from a textareas content - how are you going to put it back correctly when done spell-checking?) - allows them to make corrections and then saves the revised text back to its associated field.

Not sure of what utilities exist for doing this kind of thing - Dave's recommendation is probably good - but I think you're going to need more.

Migrateduser

I think the most complicated piece of this will be the UI / presentation layer. Actually doing the manipulation might be somewhat straight-forward but if your users don't understand the limitations of the technology you're working with, they're likely to demand something that is either impossible or hardly feasible.

ryandev

The requirement was to have a split screen (frames) with open DCR on one side, and outputted word-doc on the other.

So far, the word document outputs fine. The problem I've ran into, was DCTs that contain VFE fields. The OOTB VFE javascript seems to access everything via absolute references (top and opener) rather than relative (parent).

Since the DCT is opened in 1 additoinal layer (frame) then everything breaks when it comes to the VFE fields.

I end up with no problems with DCTs with no VFE -- and a large slew of errors when the VFE is involved.

Has anyone had experience having a DCR field open in a frame? (and work with VFE fields?)

Johnny

What's your base requirement - from your post it sounds like it's just a matter of spell check.

Can you not rely on the VFE spell checker?
It may not be feasible, but there are IE toolbars you can install (google is one of them) that can spell check form fields for you.

I think there's a simpler way of meeting your requirement.

The requirement was to have a split screen (frames) with open DCR on one side, and outputted word-doc on the other.

So far, the word document outputs fine. The problem I've ran into, was DCTs that contain VFE fields. The OOTB VFE javascript seems to access everything via absolute references (top and opener) rather than relative (parent).

Since the DCT is opened in 1 additoinal layer (frame) then everything breaks when it comes to the VFE fields.

I end up with no problems with DCTs with no VFE -- and a large slew of errors when the VFE is involved.

Has anyone had experience having a DCR field open in a frame? (and work with VFE fields?)

ryandev

No such luck with a Base requirement. Business are very picky and don't want a simple spell check. They want to use word (with different languages set as default). As it is a large corp, we can't have everyone install something new/different for this feature request that is only used by the few people who use Teamsite.

Not all fields that they want spell checked are VFE fields - but some are. The requirement was to just see the spelling mistakes in the word document and fix them in the open DCT.

Just wish there was a way to make the open DCT think it is at the "top" and the "opener" ... fool the JavaScript into thinking it is open in its own browser, rather than inside a frame.

As a last resort, I'll open 2 windows.

Migrateduser

I don't think you can do this with "top" but I think you can with "opener"...

What if you were to state in whichever window you want to feign as the opener:

opener = self;

? You may need a 'var" before opener and you also might get "Access denied." or some other retarded Javascript error but I think I've done this before with faking a window as being the opener and it's worth a shot.