I have several reports set up in a form using
var rpt = new Report()
...[stuff in between]
var doc = rpt.open("Document")
I generate the reports with a mouse up action attached to a button.
I have found that after I generate a report with one set of data, then reset my form, import another fdf file and generate a report with the second data set, the report still contains data from the first fdf file. I am certain the fields containing that data are among those designated to be reset, however, the data is not immediately purged by the resetForm() action, even though that data is replaced in the form with data from the imported second fdf file.
This occurs even if I save the form after importing the second data set. If I wait a few minutes, eventually - within a short time - the first data set IS replaced ('behind the scenes') by the second data set and the generated report is then accurate. I am concerned with this because it could easily result in inaccurate reports which, if not noticed, could cause unhappy report recipients.
Is there some measure I can take to defeat this anomaly?
Data retained in form or memory after resetting a form
2011-02-11 18:05:32
Answered
My Product Information:
Acrobat Pro 9.4, Windows
Acrobat Pro 9.4, Windows
2011-02-11 21:03:22
#1
What you're describing sounds very odd, and I suspect a problem with the code you're using. Can you post more?
2011-02-12 03:50:15
#2
Accepted Answer
resetForm() resets the fields specified. The calculations involved with that reset (which is essentially setting the field's value to its default value) updates variables which are set in the calculations. All other variables remain unchanged.In order to reset these variables, you will have to reset them in your own resetting script. This resetting script may contain the resetForm() command, of course. This should then take care of the artefacts you encounter when you reset and then import a new FDF.
Now, if you close the document, the variables are still around in memory, and there is a process called "Garbage Collection" which clears them up. I don't know the exact time interval when the Garbage Collection process is started within Acrobat, but it may actually be several minutes (and things may be even more different in Windows, where each document window is its own process). So, you may actually encounter the effect that the Garbage collection has not yet done its work.
As this is a process within Acrobat (and also within the operating system), you have no access to it (except maybe via a plug-in…maybe). Therefore, there isnot much you can do about it. However, I think resetting the variables, in particular the "doc" variable (also consider another name for it; it might be a reserved name), you should no longer have the effect.
HTH.
Max Wyss.
2011-02-12 09:04:57
#3
What Max is describing highlights the importance of coding so that you do not unnecessarily create document-global variables. It is usually very easy to avoid, or mitigated if you absolutely need to have them.
2011-02-12 10:54:02
#4
Well this is very educational. My issue sounds like a "garbage collection" issue.
Before I forget to ask, I would like to know more about George Johnson's comment about unnecessarily creating document-global variables. I did not know that was to be avoided. I have a bunch. I have found that when my variables are defined globally, the scripts that act on them do their job faster and my form works much quicker than when the variables are defined in scripts attached to individual fields. The more variables in the script, the more pronounced the speed improvement. Therefore, I would appreciate knowing more about the down-side of creating document-global variables.
The fields whose values are hanging around are text fields with no default values. My form is an 8 page form with in excess of 300 fields, some of which are used for field labels that show/hide of necessity. When I reset my form I don't want to reset a good number of fields. I have a reset function defined, shown below in abbreviated form but substantively accurate:
function ResetMaster()
{
var fields = new Array()
fields[0] = "txtB" //most of these are parent fields encompassing many
fields[1] = "txtBP"
fields[2] = "txtBE"
// with fields [3] through [41] in between
fields[42] = "txt.Parties"
fields[43] = "txt.CommonAddress" //these 43 items encompass about 150 fields.
this.resetForm(fields)
}
Before I forget to ask, I would like to know more about George Johnson's comment about unnecessarily creating document-global variables. I did not know that was to be avoided. I have a bunch. I have found that when my variables are defined globally, the scripts that act on them do their job faster and my form works much quicker than when the variables are defined in scripts attached to individual fields. The more variables in the script, the more pronounced the speed improvement. Therefore, I would appreciate knowing more about the down-side of creating document-global variables.
The fields whose values are hanging around are text fields with no default values. My form is an 8 page form with in excess of 300 fields, some of which are used for field labels that show/hide of necessity. When I reset my form I don't want to reset a good number of fields. I have a reset function defined, shown below in abbreviated form but substantively accurate:
function ResetMaster()
{
var fields = new Array()
fields[0] = "txtB" //most of these are parent fields encompassing many
fields[1] = "txtBP"
fields[2] = "txtBE"
// with fields [3] through [41] in between
fields[42] = "txt.Parties"
fields[43] = "txt.CommonAddress" //these 43 items encompass about 150 fields.
this.resetForm(fields)
}
2011-02-12 11:40:40
#5
You said the data is not immediately purged when you execute a resetForm statement, but that the new FDF does fill the fields with new data. The resetForm will reset the field values, but not any variables that may contain values extracted previously from form fields. So you will have to again populate those variables with the new form field data after you import a new FDF.
The function you showed does not create any document-global variables. The "fields" array variable is local to that function.
What I've been calling a document-global variable is created when you define a variable (with or without the var keyword) in any event if it's outside of a function. I'm surprised to hear that there's any sort of performance penalty, so we may be talking about different things. It's really hard to tell what's going on without seeing more of your code.
Global variables can lead to all sorts of bugs that can be difficult to track down and should always be avoided when possible, and it usually is.
As an aside, you should also always end a statement with a semicolon. Not doing so can lead to subtle bugs, so it's a good thing to get in the habit of always using them. The fact that JavaScript lets you get away with not including them is a defect of the language in my opinion, and the opinion of many who are more proficient than me.
The function you showed does not create any document-global variables. The "fields" array variable is local to that function.
What I've been calling a document-global variable is created when you define a variable (with or without the var keyword) in any event if it's outside of a function. I'm surprised to hear that there's any sort of performance penalty, so we may be talking about different things. It's really hard to tell what's going on without seeing more of your code.
Global variables can lead to all sorts of bugs that can be difficult to track down and should always be avoided when possible, and it usually is.
As an aside, you should also always end a statement with a semicolon. Not doing so can lead to subtle bugs, so it's a good thing to get in the habit of always using them. The fact that JavaScript lets you get away with not including them is a defect of the language in my opinion, and the opinion of many who are more proficient than me.
2011-02-13 09:51:32
#6
I did not mean that my global variables were in the function described in my post above. The use of global variables and the "garbage collection" issue are two separate topics, so perhaps I should have split them into separate responses.
My global variables are defined separately as in this small sample:
var gSSalutation = this.getField("txtS.Salutation")
var gSPhoneWork = this.getField("txtS.Phone.Work")
var gSPhoneHome = this.getField("txtS.Phone.Home")
var gSPhoneMobile = this.getField("txtS.Phone.Mobile")
which I don't imagine is the least bit unique.
With respect to your first paragraph above, how do you populate variables after importing a new FDF?
As to the performance issue, I have a number is scripts that show/hide and reset field values (to "" to clear data from hidden fields), affecting 20 or 30 or more fields per script. After experimenting with defining those variables in scripts attached to the field initiating the action, and defining them globally and placing the script in a function, then calling the function from the initiating field, there is no doubt in my mind the script does its thing noticeably faster with the latter approach.
My global variables are defined separately as in this small sample:
var gSSalutation = this.getField("txtS.Salutation")
var gSPhoneWork = this.getField("txtS.Phone.Work")
var gSPhoneHome = this.getField("txtS.Phone.Home")
var gSPhoneMobile = this.getField("txtS.Phone.Mobile")
which I don't imagine is the least bit unique.
With respect to your first paragraph above, how do you populate variables after importing a new FDF?
As to the performance issue, I have a number is scripts that show/hide and reset field values (to "" to clear data from hidden fields), affecting 20 or 30 or more fields per script. After experimenting with defining those variables in scripts attached to the field initiating the action, and defining them globally and placing the script in a function, then calling the function from the initiating field, there is no doubt in my mind the script does its thing noticeably faster with the latter approach.