Avoka Blog: Adobe LiveCycle

July 30, 2008

A fix for some cosmetic differences between Reader 8 and 9

Filed under: Designing Forms, LiveCycle — htreisman @ 5:07 pm

When Reader 9 starts up, by default it clicks the “Highlight Fields” toggle button. In Reader 8, this was unchecked by default.

In general, this is a good thing. It makes it much more obvious to end-users which documents are fillable/editable PDFs, and which are plain PDFs that can only be printed.

However, in some cases, where your user-base is already expecting fillable forms, this means that all your carefully color-coordinated forms now don’t look as good on startup.

Another issue is when you have required fields, which show up with red borders – apart from looking a bit garish, our usability testing has indicated that it can make new users freak out, thinking they’ve already made a mistake before they’ve even done anything.

This is compounded if you have fields with caption above the field, which in Reader 9 is rendering as two red borders, as shown here:

There is a very simple way to preserve the Reader 8 behavior – simply add the following line to the root node of your form:

On Initialize
app.runtimeHighlight = false;

This has been tested in Reader 8.1 and Reader 9.

Note: In Reader 9 the “Highlight Fields” seems as it is clicked even though this line of code deactivate it. Therefore, If you want to click it to highlight the fields you have to click it twice for the first time (1.Deactivate 2. Activate).

Thanks to Mohammad Al-omari for coming up with this code.

Avoka has a LiveCycle Forms JavaScript library that allows you to handle validation errors in a more graceful way, as well as providing a whole lot of other useful utility functions that makes building forms easier, quicker, and more effective. If you’re interested in more information about this library, please email info(at)avoka.com.

July 8, 2008

Form Guide Rendering Explained – Part II

Filed under: LiveCycle, LiveCycle Architecture — htreisman @ 6:12 pm

A number of people (Gareth and Mark from Adobe – thanks guys) indicated that the first blog on this topic was correct, but incomplete.

Here is the rest of the story…

Q: What is an orchestration?

A: An orchestration is really a LiveCycle process that runs as if it were really just Java code. You design an orchestration by dragging a series of steps into a “short-lived” process, and joining those steps together using lines. Each step is really a method call on an object, and the process engine simply follows the lines, and executes each method call in the correct order. It’s basically visual programming.

You can invoke an orchestration from Java or C## or other code, via SOAP, from another orchestration, etc. When you call it, it’s almost identical to calling a real Java program, except that:

  • The logic of the code is visible graphically
  • It can be maintained and modified by non-programmers
  • It’s much easier and quicker to change
  • It runs a teeny bit slower than if you’d written the code in Java

There is a sample orchestration for rendering a Form Guide as a step inside of LiveCycle Workspace – you can refer to that if you want to take a closer look at both an orchestration, and also an orchestration rendering a Form Guide.

Q: What if I’m using the feature where you can switch between the Form Guide and a PDF?

A: Well, things do get a little more complicated.

Form Guide With PDF

Form Guide With PDF

In this case, a few extra things happen:

  1. After loading the SWF file, the SWF file checks to see whether the minimum version of Reader/Acrobat is available.
  2. If so, creates a new, hidden DHTML iframe.
  3. Into the iframe, it loads a URL that points back to the LC Forms servlet.
  4. When invoked, the servlet in turn invokes the LC Forms Render process. It supplies different parameters, this time requesting a PDF to be returned, rather than SWF.
  5. The PDF is returned to the hidden iframe.
  6. The Form Guide enables a button that allows the end user to toggle between the Form Guide and the PDF view.
  7. When the user clicks the PDF toggle button, the Form Guide extracts the current state of the XML contained in the Form Guide, and dynamically injects it into the PDF.
  8. The Form Guide then hides itself, and displays the iframe containing the PDF.
  9. When the user toggles back, the current value of the XML is obtained from the PDF, and injected back into the Form Guide, and the hide/show happens.
  10. Voila


  • The injection of XML data into the PDF is achieved using something called the Form Bridge, which is a combination of JavaScript in the form itself, and some Javascript in the iframe. This basically allows the Form Guide to communicate to the PDF. You can either manually insert the Form Bridge into your form (in Designer, look for it in the Custom palette), or you can dynamically inject the Form Bridge into your form in the orchestration, using a service called the Form Augmenter.
  • Like the generation of the Form Guide SWF itself, the PDF will also be cached by LC Forms – on subsequent invocations, the PDF will be obtained from the cache.

Please click on the “Comments” link for some excellent additional material – a big thank you to John for contributing.

Blog at WordPress.com.