Archive for February, 2009

LiveCycle Forms7: how to disable client-side caching


 If you are using FormServer 7.1 you may want to disable client-side caching.  This will prevent previously entered values from appearing on a new form when you open it in a fresh browser instance.


The problem is that Acrobat/Reader is caching the form (along with its data). It does this based on the URL address (same URL = same form/data). Unfortunately, since this is a client setting there is no easy way to disable it.


Here are some suggestions to achieve this:

1) on the form (i.e. will be on a form by form basis):

add this code into the form:ready event –

var oDoc =; 

oDoc.nocache = true;

2) make the URL unique:

An easy way of doing this is to return a date/time stamp as an unused parameter in the URL. This can be easily added by either the JSP or the servlet. For example:


3)  Also consider setting the cache control headers in your response:

// Set content to expire far in the past. 
response.setHeader("Expires", "Thu, 1 Jan 1970 12:00:00 GMT"); 

// Set standard HTTP/1.1 no-cache headers. 
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate"); 

// Set special IE extended HTTP/1.1 no-cache headers (use addHeader). 
response.addHeader("Cache-Control", "post-check=0, pre-check=0"); 

// Set standard HTTP/1.0 no-cache header. 
response.setHeader("Pragma", "no-cache");


reference: (1-28022235)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Acrobat/Reader: how to display the attachment panel automatically in XFA forms


The attachment panel in Acrobat/Reader does not appear automatically, even when the document does actually contain attachments. It is a common requirement to have the attachment panel show up automatically when opening a form which contains attachments.


Use the following instructions to check for attachments in the document, and if attachments exist, then show the attachment panel.

1. you will need to edit the form in LiveCycle Designer.

2. add a Button object to the form from the standard library.

3. set the presence of the Button to “Invisible” in the Field properties of the Object Palette (on the right-hand side).

4. goto the click event of the button at the top and enter the following client-side Javascript:

var myDoc =;
var d = myDoc.dataObjects;
if ( d == null ) {
// do nothing
} else {

5. then open the doc::Ready event of the form itself and enter the following client-side Javascript to call the click event of the button when opening the form:


6. save the form

Note: This solution will work for Acrobat 8. If you wish to use Reader 8, then the solution above will only work if you enable the form with ReaderExtensions server.

Note: To use this solution in Acrobat/Reader 7, then you will need to change the “ShowHideFileAttachment” key to “ShowHideAttachments".

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 2.0/10 (1 vote cast)

LiveCycle Forms7: importXMP() throws a PDFOperationFailure if the data contains accented characters


 If you are using the importXMP() method from the FormServer 7 API to import XMP metadata to a PDF you may receive a PDFOperationFailure exception in the log similar to the following:

[11.07.06 13:55:50:837 CEST] 16fd9246 SystemErr R omniORB: WARNING --method 'importXMP' 
on: root/req-66<16777216> raised the exception: IDL:com/adobe/document/pdf/PDFOperationFailure:1.0
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x0 minor code: 0 completed: Maybe
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R


This exception is caused by accented characters in the XMP metadata.  Removing the accented characters will allow the importXMP() to complete successfully, so there is obviously a problem with the encoding.


 You may be using the following code to generate the data:


To resolve the issue you must set the encoding to UTF-8 if there are accented characters:


reference: (1-27943601)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycle Designer: parseInt parses numbers based on a base/radix


If you are using the parseInt() method in Javascript, you may receive some unexpected results. This is especially true if you are using any kind of prefixes in the value.

For example:

parseInt(“09”) would return “0”

and parseInt(“045”) would return “55”


Use parseFloat() to get expected results for numbers that are prefixed with “0”.  Use parseInt(“09”, 10), where 10 specifies the base, that is, decimal.

Additional Information

The “0” prefix causes the unexpected results from parseInt(). Numbers with a “0” prefix are taken as octal (base 8 ) numbers as opposed to decimal numbers. As a result, the octal 55 is equal to a decimal 45.

parseInt syntax: parseInt('string' [, base])

How it works:

The first argument of parseInt must be a string or a string expression. The result returned by parseInt is an integer whose representation was contained in that string (or the integer found in the beginning of the string). The second argument (base), if present, specifies the base (radix) of the number whose string representation is contained in the string. The base argument can be any integer from 2 to 36.

If there is only one argument, the number base is detected according to the general JavaScript syntax for numbers. Strings that begin with 0x or -0x are parsed as hexadecimals; strings that begin with 0 or -0 are parsed as octal numbers. All other strings are parsed as decimal numbers.

If the string argument cannot be parsed as an integer, the results will be different in different interpreters (either 0 or NaN).

Examples (comments in each line give the conversion results):

parseInt('123.45') // 123
parseInt('77') // 77
parseInt('077',10) // 77
parseInt('77',8) // 63 (= 7 + 7*8)
parseInt('077') // 63 (= 7 + 7*8)
parseInt('77',16) // 119 (= 7 + 7*16)
parseInt('0x77') // 119 (= 7 + 7*16)
parseInt('099') // 0 (9 is not an octal digit)
parseInt('99',8) // 0 or NaN, depending on the platform
parseInt('0.1e6') // 0
parseInt('ZZ',36) // 1295 (= 35 + 35*36)

reference: (1-16936533)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)

LiveCycle 7: disable “An active transaction should be present…” message from the WebSphere log output


 If you are running LC7 products in the WebSphere application server you may notice the following message appearing repeatedly in the log file:

[21/09/07 15:40:24:562 IST] 72d82e0c ConnectionMan W J2CA0075W: 
An active transaction should be present while processing method allocateMCWrapper.
[21/09/07 15:40:24:578 IST] 72d82e0c ConnectionMan W J2CA0075W: 
An active transaction should be present while processing method initializeForUOW.

You may want to disable this message, to prevent it appearing in the log.


This message can be ignored as it is merely an informational message.  This message can appear so much, that it starts to fill up the log and makes it very difficult to see any actual problems in the log.


To simply suppress the messages from being logged to the SystemOut.log, do the following:

Open the <WEBSPHERE_HOME>\properties\ file in a text editor.  Find the following block:

<!-- The cm-properties are in a comment block. Uncomment to use -->

Remove the comments and change the true to false.  It should look like the following once complete:

<!-- The cm-properties are in a comment block. Uncomment to use -->

reference: (1-25647507)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)