Posts in Category "General"

Submitting crash information using Windows Error Reporting

Starting with Designer 8.2.1, you can submit crash information using Windows Error Reporting. When you submit crash information, it would be helpful if you could log a bug and provide the steps required to reproduce the bug as well as the crash bucket ID assigned by Windows Error Reporting. Logging a bug will go a long way in helping us find the cause of the problems.

  1. Go to www.adobe.com
  2. Click the Send feedback link at the bottom of the page.
  3. In the Adobe Products section, click Report a bug.
  4. In the Product name list, select Designer.
  5. Provide the steps to reproduce the crash.
  6. Provide the crash bucket ID.

To retrieve the Windows Error Reporting Crash Bucket ID

Windows XP

  1. Select Control Panel -> Performance and Maintenance -> Administrative Tools -> Event Viewer.
  2. In the left pane, select Application.
  3. In the Application list, you should see two log messages called “Application Error” at the time Designer crashed. One of the log messages identifies the crash as being from “FormDesigner.exe”. The other message identifies the crash bucket ID that Windows Error Reporting associated with the crash. The number called “Fault Bucket” is the number you need to include in the bug report.

Windows Vista

  1. Select Control Panel -> System and Maintenance -> Problem Reports and Solution.
  2. In the Tasks list, click View problem history.
  3. Locate the section of problem history for LiveCycle Designer ES.
  4. Double-click on the event that correspond to the date and time of the crash.
  5. Click the “Copy to clipboard” link and past it into the bug report.

Windows 7

  1. Select Control Panel, search for “Problem Reports”, and then click on “View all problem reports”.
  2. Double-click on the event that corresponds to the date and time of the crash.
  3. Click the “Copy to clipboard” link and past it into the bug report.

Thank you
The LiveCycle Designer team

An example of splitting text across two fields

I went on a customer visit and was asked to solve an interesting problem. Basically, this customer had a regulatory PDF form. The form’s layout couldn’t change, and at the end of a workflow process, the form was printed as a document of record. This form was very complicated, with lots of special logic (i.e. “if field 2b is filled, then options 7a, b, and d are no longer available”.) The customer opted to try out Adobe’s Form Guide technology to make the form filling experience better, but once the Guide was complete, we had to take the data from the Guide and push it back to the PDF form (using LiveCycle) and then print the PDF form to paper.

This form had many small fields with instructions indicating that if the field couldn’t contain all the info, to add an appendix page with the rest of the text. Now, in most cases, we would encourage clients to make fields growable, so that they will just expand to fit the text put in them and all the subsequent form content will move down. However, in this case, due to the need for the form to preserve it’s original layout for printing, we couldn’t do that.

It was actually hard to solve this problem: we tried many different scenarios, but most of them were dead ends. The essential problem we kept running into was that the XFA model just doesn’t provide the information you would need to calculate or extrapolate how much text can fit in a given field.

The only solution we came up with that worked fairly well is in the form below. It involves using a fixed-width font in the fixed field, so that reasonable assumptions can be made about how much text can fit into a given field. There’s script that parses text and splits it between two fields. The script is heavily commented, so hopefully readers can figure out what’s going by reading the code.

A form that splits text between nodes

Spell Check Locale Mapping

Following a customer request, we’ve added a new mini feature to Spell Checking in Designer.  At the moment, Designer supports spell check for about 35 different locales.  Before the magic of locale mapping, if your locale wasn’t on the list, your were essentially out of luck; even if your locale was, for all practical purposes, identical, to a supported locale.

Let me provide an example of customer pain. 

Say you’re Australian.  Aussie English is actually quite similar to Canadian English.  However, if you set your form’s locale to en_AU, you’ll get cute little warning icons telling you that spell check doesn’t support en_AU.  And you’ll sit there fulminating, thinking “Geez!  Aussie English is *practically* Canadian English!  Why can’t this stupid program just use the Canadian English settings for spell check?!”

Of course, you could get around this limitation by, say, setting your form to en_CA, doing the spell check, and then changing it back – but that’s a real pain.

Now there’s a better, easier, way.

There’s now a new file, SpellCheckLocaleMapping.xml, that is created in each user’s Designer data directory (under …\Users\your_username\AppData\Adobe\Designer\8.x).  In this XML file, users can add entries that tell Designer to use alternate locales for spell checking.

The file looks like this:

<LocaleMap>

<!– In order to map spell check locales, add an entry for each locale to map:

<Map locale=”en_AU” to=”en_CA”/>

Where “locale” is a locale which does not support spell check and “to” is the locale that will be used to perform spell check on nodes who’s locale matches “locale”.
–>

</LocaleMap>

You can just copy/paste the <Map …/> line so that it’s not in the comments anymore.  Then set the “locale” and “to” attributes.  You need to restart Designer for changes in this file to take effect.

This feature is available in Designer 8.1 and later. There’s no UI in Designer for this feature.

FormCalc Syntax Error Tips

FormCalc has a few possible syntax errors, and they aren’t always easy to decipher. Here’s a tip for when you get the “Syntax error near token ‘%1′ on line %2, column %3.”:

Generally, %1 will contain the token (word) nearest to the error. Please note that the token is not necessarily incorrect, and does not necessarily have anything to do with the error, other than proximity to the problem.

var b = abc(1)
if (b ne 1) then
//comment

The script above will generate a 7008 error: “Syntax error near token ‘then’ on line on line x, column y.” The actual error in this case is that the ‘endif’ token is missing from the script. The last correct token is ‘then’ (comments do not count as tokens.)

The way to fix this problem would be to add an ‘endif’ statement to the end of the script.

Learning Resources is putting together more extensive documentation for the syntax error messages which will hopefully be available on the Web shortly after we ship 8.2.

Welcome to Designer Exposed

Welcome to the LiveCycle Designer Team’s “team blog”. A place where we’ll post useful tips on how to use Designer, in-depth articles about new features, etc. We hope this will enhance the user forums (at www.adobeforums.com) and gives our developers an opportunity to provide “from the trenches” information about the product.

While we plan to post articles here, please continue to use the Forums for questions (and for suggestions about future topics for this blog). When we post an article here, we’ll link to it from any relevant questions in the Forum.

LiveCycle Designer Team