COM debacle

[largyres]

We use ACL COM commands com_attach etc. to open Word files and run Word macros. (Arbortext 6.0M050 64-bit; Win 7)

# open named word file and run macro: h - Word COM handle; docsh - Documents collection; doch - doc to open[; docapp - Application property; docapprun - Application.Run macro method]

h=com_attach('Word.Application');

com_prop_put(h, 'Visible', -1);

com_call(h,"Activate");

docsh = com_prop_get(h, 'Documents');

doch = com_call(docsh, 'Open', word_doc);

if (word_macro) {

docapp = com_prop_get(doch, 'Application');

docapprun = com_call(docapp, 'Run', word_macro);

}

com_release(h);

}

Process is (1) "write" 2 versions of a file with Tracked Changes (-ct changesapplied | original); (2) XSL transforms 2 versions to WordML (Word 2003 XML Document) format files; (3) open 1st Word file and (3) run macro that compares it to reject-all "original" version (believe me, you don't want to write an XSL that transforms <atict:> tags to WordML). Result files showing Tracked Changes are sent to outside authors/reviewers who don't have Arbortext.

Lou Argyres

CEB / Continuing Education of the Bar

510-302-2097 | lou.argyres@ceb.ucla.edu | ceb.com

UNIVERSITY OF CALIFORNIA - STATE BAR OF CALIFORNIA

[GarethOakes]

> So what's different between Word 2010 "stand-alone" and Arbortext "COM" modes?

Firstly I should note that COM is a standard Windows technology for inter-process communication, so it is not "Arbortext COM" if you see what I mean 🙂 That might have already been obvious, apologies if so.

The main difference might be the process permissions. What user is Arbortext running as vs standalone MS Word? Are they the same? When Arbortext instantiates MS Word through the COM connection, MS Word will inherit the Arbortext permissions, are these different?

You could test the theory by having the files written to a "readable/writeable by Everyone" temp folder and see if that helps with the "file not found" errors?

Just some thoughts, hope they help. In the past we have encountered many COM issues due to differences or mismatches in permissions.

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

[largyres]

I'm acquainted with COM only thru the handful of ACL functions so thanks
for setting me straight Gareth.



It's looking like more restrictive "security" settings in COM
implementation of Word 2010 VBA won't allow processing files on a
network path (the macros that process "stand-alone"), so you were right
regarding permissions.



Microsoft lost me post-2003 with that stupid Ribbon, so I'm doing this
"upgrade" reluctantly. Besides not being able to find anything, we're
finally moving in a paperless direction with many people working on
skyscraper monitors, and the inability to bring floating controls down
into the work area is a real minus.



Lou Argyres

CEB / Continuing Education of the Bar

510-302-2097 | lou.argyres@ceb.ucla.edu | ceb.com