To summarize where we are, we've been trying to find a way to store functions as
persistent globals, so that we can come back to them, from ANY future PDF form that our
reader downloads from our site, and use the code that's stored there. It's kind of like
being able to take a bathroom break during the Scholastic Aptitude Test, and having the
Cliffs Notes to Euclid's Geometry already stored behind the toilet in the men's room. We
want to be able to put whatever Cliffs Notes we want, behind whosoever's toilet we want.
What we've figured out so far is that we can convert a function to a string with
with the built-in Function constructor. But in order to use the latter, we have to supply
the "guts" of the function as a string, minus the declarative "function funcName(args)"
prefix. We developed a regex to clip that prefix off of function declarations yesterday.
But we also have another problem to deal with, namely the problem that toString()
introduces unwanted formatting into the strings it produces! Weirdly enough, it turns out
that this function inserts newlines and spaces willy-nilly, to format our code, whether
that's what we wanted or not. The reason this is a problem for us is that when we put the
resulting string into a persistent global, and then that global gets read into memory again
later (at the start of another session), the newlines cause errors of the "unterminated
string literal" kind.
The answer to the latter problem is another regex. All we have to do is pass the output
str = str.replace(/\n/g,"");
This regex-replace operation is applied globally (because of the lowercase 'g') to all
newlines. And since the replacement string is null, we end up deleting all newlines, plain
and simple. Problem solved.
The Magic Formula
So, in order to store a library function as a persistent global, here is what we have to
Read the global string into a variable (optional).
var s = global.f1;
Construct a new function.
var newFunc = new Function("a",s);
Use the new function just like you would the old one.
x = newFunc( a );
The 'a' in the Function constructor is the argument that the old function took (if any).
Some functions have multiple args, some have none; obviously you'll have to tailor this part
to the situation, although I hasten to add that as an exercise, you should be able to devise
a general solution (one set of code fitting all situations) using regexes, arrays, and/or
common sense. We've already complicated this discussion enough with regexes, so I won't go
there any more just now. However, I do encourage you to play with the above recipes for
storing and reconstructing functions as persistent globals. Maybe you can find ways to
improve on my scheme through the use of arrays, concatenated strings (join/slice methods),
etc. In fact, I'm sure you can find many ways to improve on this scheme. All I was
trying to do is determine a way in which persistent storage of library functions
could be done. At all.
Checking to See If a Global Exists
Before I stop today, I want to give a tip for checking to see if a global already has
easy to check a variable for validity. But in this case it turns out to be easy. You can
check a global this way:
testing it is easy. Use this trick to test whether your library functions (above) are
When you want to make a variable global, but not necessarily persistent, you do NOT have
to store it in the Global object explicitly. Just go up to the Tools:Forms:Document
(Delete the function skeleton.) For example, enter gMyVariable = 0; and hit OK to
dismiss the dialog. (Don't type a function.) From that point on, gMyVariable will be
globally available throughout your document, to any function that needs it. And, not only is
it available throguhout the current document... it is available to ALL open PDF documents
OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.