Specification, Known Problem

The specification for how Helix should act when an unentered record is printed has never been clearly defined. The situation becomes more complex when Post On Print options are added.

The issue has often been raised: when a record is edited but not entered (or replaced) and the user prints the form, what should happen? Some users report that Helix discards the modified data. In researching this, we discovered that the behavior varies depending on specific (undocumented) details of the setup. This technote is an attempt to document the situation and to provide a path to a consistent specification.

This issue is being discussed in our techdb forum under R#6112. If you wish to contribute to the topic, please post your comments there.

General Rules

Rule #1: Helix prints the data that is seen on the view at the time of printing, regardless of the state (entered or not) of that data. After printing, Helix will present the standard "Save changes before…" dialog if unentered data exists and the user attempts to move away from the record. This is as it should be.

Exception #1: If there is an Option 0 post attached to the Post On Print column, the record is automatically entered after printing, when the Option 0 posting occurs. Comment: This is logical, as the Option 0 post requires record entry.

Exception #2/Bug #1: If there is one or more posts attached to the Post On Print column and none of them is an Option 0 post, the data on screen is printed, but then the record is reverted to its previous state, and no posting occurs. Comment: This is considered a bug. The record should not revert after printing.

Workaround #1: If you want to ensure that the data on screen is stored after printing, include an Option 0 post.

Invalid Data

If the edited data does not pass validation checks, the invalid data is printed with the invalid data shading (if Shade Invalid Fields is turned on for that view), indicating the validation failure.

Exception #1: If there is an Option 0 post attached to the Post On Print column, the record is automatically entered after printing, when the Option 0 posting occurs, and the invalid data is stored in the record. Comment: This is a conflict, as the Option 0 post requires record entry, but invalid data should never be stored.

Exception #2: If there is one or more posts attached to the Post On Print column and none of them is an Option 0 post, the data on screen is printed, but then the record is reverted to its previous state, and no posting occurs. Comment: This is considered a bug. The record should not revert after printing.

Because of the invalid data, an impossible conflict is presented. It remains to be determined whether:

1. printing should be disallowed until all data passes validation
2. the data should be reverted to its valid state
3. printing should be allowed, printing the invalid data, but the record not entered until the invalid data is corrected

Your feedback is welcome.

Incompatible Data

If the edited data is incompatible with the field type (e.g. text in a number field) the incompatible data is thrown away — i.e. the field is reverted &mdahs; before printing occurs. For all other fields on the view, the rules described above are applied.

New Records

When Post on Print is triggered on a new, unentered record, Helix prints the data that is on the view, but the record is not created until the user takes further steps to enter the record. The Post on Print operation occurs as designed even though the record has not yet been created.

Option 0 Post Exception: Unlike the scenarios described above, an Option 0 post does not force creation of a new record. Instead, when the user attempts to move away from the record, the standard "Save changes before…" dialog appears. This can lead to some unintended consequences:

1. If the user successfully enters the record, the Option 0 posting occurs.
2. If the user chooses to discard the new record, the Option 0 post does not occur and non-Option 0 posts are not reverted.
3. If a field contains data that fails a validation check, the invalid data is printed, but the field must be corrected before the record can be entered.
4. If a field contains incompatible data (e.g: text in a number field), the incompatible data is reset to the last valid data state (a previously typed or defaulted value, or undefined) before the printing occurs. If the field previously contained compatible, but invalid data, the invalid (but compatible) data is printed. After printing, the cursor remains in the incompatible field, and the data must be corrected before the record can be entered.

The question has been asked: when a post icon is attached to a view in the ‘On Print’ column, when does the posting actually take place? This is important to know when considering the effects of a write-locked record or other problems (e.g: paper jams) that prevents the print job from completing.

First, a word about templates. In Helix a (page layout) template can be designed as a single page or a span of multiple pages, each with a distinct layout. Multiple page templates (described in section 8.1.11 of The Helix Reference) can be identified by the presence of page boundary lines in the layout area. In the case of a template designed to print multiple, distinct pages, each group of pages is considered one ‘Template Page’ — not to be confused with a single page template that prints multiple copies of the same page.

In Helix 6.1 and later, post icons attached to the ‘On Print’ column occur one ‘Template Page’ at a time. This is straightforward in the case of a single page template: print page 1, post record(s) on page 1, print page 2, post record(s) on page 2, etc.

But in the case of multiple page templates, it is important to understand that no records are posted until the entire template page has printed. So, in the case of a two page template the order of events would be: print page 1, print page 2 (the first pass through the template is now complete), post record(s) on pages 1 & 2, print page 3, print page 4 (the second pass through the template is now complete), post record(s) on pages 3 & 4, etc.

Together with the new specification for printing page ranges, it is possible to print pages that do not post, and to post pages that do not print. Consider a page template that spans two physical pages. Posting will not occur until the template page (both pages) completes. If you specify a print range of ‘1 to 1’ then the template page will not complete and no posting will occur. Conversely, if you specify a print range of ‘2 to 2’ then the template page will appear as complete (the 2nd page of the 2 page template having printed) and the posting will occur for both pages on the template.

Because of these situations, and because it is impossible to predict physical printing failures once the print job has spooled, it is our general recommendation that Post on Print not be used. Consider printing as a first step and then using Post All to mark the records as printed.

The term ‘Print’ in this discussion refers to the process of sending the data from Helix to the printer driver. Paper jams, low ink, etc. can all interfere with the physical aspect of printing the pages. Once the page is sent from Helix, it is assumed that the printer will successfully print the page.

For multiple page templates, this is different from prior versions which posted each physical page as it printed.

These issues have affected all versions of Helix. Specification changes have been made in Helix 6.1, and bugs have been fixed, but there is still work to do.

This is an evolving issue. The latest information can be found in Report #6112 in techdb.