Check this out -- it's an article on PlanetPDF. Basically Adobe has a version of ECMAScript (javascript) implemented inside PDF.
http://www.planetpdf.com/developer/article.asp?ContentID=6622The article indicates that AcroJS can be scripted on the Application or Document level, which means that it's outside the document. At first glance, it looks like this is what you would prefer.
Checking the AcroJS specification, a document has a numFields property and a getField method.
However, I'm not sure how any of this will help you with the OCX.
First, there would be security problems with allowing script outside the document to manipulate the document like that, especially capturing userinput. So even if it worked in some contexts, it might not work in others.
IOW: You mentioned that you have 300 documents. It looks like you can create a generic script for all documents, but for security reasons you might still have to place this script *inside* each of the 300 documents for it to work consistently. Does that make sense?
Second, my understanding is that the OCX is designed to work as a browser plugin, not meant for development efforts outside that context and therefore probably not very well supported or documented.
Third, it sounds to me as if the problem you're facing is a licensing/$ issue rather than an inadvertent implementation issue. IOW, Adobe wants a full version of Acrobat on the client machine because... well, it's pretty obvious, really<g>.
PMFJI here. Not my area of expertise, but I was interested for various reasons. Basically, I'm not sure how acroforms. eforms and Adobe XML Architecture fit together and was looking for an excuse to find out <s>.
>L<
