|R6112: Printing and Unentered Records|
Since Helix’s earliest days, the specification for how Helix should respond when an unentered record is printed was never clearly defined. This led to behaviors that were buggy, confusing, and sometimes required workarounds to preserve data integrity.
The situation is made even more complex when Post On Print options are factored in: views would respond differently depending on which posting options were used. The complexity further increases when Client/Server operations are factored in.
Helix 6.1.6 and later address these issues, creating a comprehensive specification that a collection designer can rely on. Even so, there are still logical pitfalls the unsuspecting designer can fall into. This technote addresses these areas.
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? Should Helix print the stored record even though it does not match what is on screen, or should it print what is on screen even though the user may later choose to discard the changes? Should the modified data be discarded, or automatically stored? If the view uses Print Posting features, which values should be used to calculate the posting: the stored values or the typed-but-not-yet-entered values?
The new specification clarifies all of these situations, resulting in a consistent behavior that offers the user additional options when printing unentered records. It also offers collection designers a clear specification to work with when creating Helix-based applications.
This technote details the new specification and documents the changes which debuted in Helix 6.1.6; Users of older versions of Helix should consult the legacy version of this technote to understand the behavior in prior versions.
Helix has always had the ability to print unentered record data (just as any other program can print an unsaved document), but Helix’s Print Posting option adds a wrinkle that creates a serious data integrity issue: How can you post based on data present on the form when that data can be discarded after printing?
To address these issues, the Save Changes before … dialog now appears when printing a view that contains unsaved changes. As with the other instances of this dialog (such as Clear Form or Close), the standard buttons Enter (or Replace) and Cancel operate as expected, allowing you to store the data changes before printing, or to cancel the printing operation and return to the record for further editing.
However, the third option (Don’t Save in most situations) varies depending on the specific situation. The sample dialog boxes on the right (click to enlarge) show the possibilities.
The first dialog shows the simplest situation, which occurs when there is no posting involved. In this case, the third option is Print Unentered. This allows you to print the unsaved data — just as Helix always has in the past — returning you to the modified — but still unentered — record after printing. At this point the status of the record is unchanged, and if you subsequently attempt to leave the record without entering the data, another Save Changes before … dialog is presented with the appropriate message. (e.g. Save Changes before Closing?
The second dialog shows the results when a Find and Print All (instead of Print) command is issued. In this case, Helix needs to step through all of the records on the form, so the option to return to the unentered data is unavailable. Therefore, the third option is Don’t Save. Choosing this option discards the data changes. After the Find and Print All is completed, the view is left with a Clear Form.
The final dialog deals with the situation when posting is involved. If any posts are attached to the On Print function of that view, disregarding the changes is not an option. Therefore, the third button is removed, leaving only the choices of Enter (or Replace) and proceed with printing or Cancel and return to the unentered form. This removes all doubt as to which values are posted during printing.
AutoOpen: If the entry view is accessed via a clickable list that has AutoClose enabled, the view closes after printing. If the Print Unentered button is available and chosen, the view closes and the changes are discarded without warning.
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 — before printing occurs.
Invalid Data: The presence of edited data that does not pass validation checks adds another wrinkle to the situation. When invalid data is present, the invalid data is printed with the invalid data shading (if Shade Invalid Fields is turned on for that view), indicating the validation failure.
However, if posting is also involved, invalid data must be corrected or discarded before the printing can proceed. In this case, this additional dialog is presented with two options: Cancel Print or Discard Changes and Print. The secondary message shown in the dialog is the Why? message for the invalid field.
One bug has been discovered: If there is an Option 0 post attached, and the user chooses to Discard Changes and Print, Helix stores invalid data. This bug will be addressed in the future. The current status can be found in R7049 of techdb.
|When Does ‘Print Posting’ Actually Post?||
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. 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. This is different from prior versions which posted each physical page as it printed. For example, consider the case of a two page template. When printing this view, the order of events are: 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 multiple page templates not be used in situations where Print Posting is involved. In fact, Print Posting is generally discouraged because of the issues that can occur. We recommend using a sequence that prints as a first step, using Post All to post the records as a second step.
The term ‘Print’ in this discussion refers to the process of sending the data from Helix to the printer driver. The macOS Print Dialog has a Preview option that shows the results without sending the data to the printer, by creating a temporary PDF file. This Preview has two buttons that allow the user to proceed with the printing or to cancel the job. Helix does not attempt to discern whether the user actually prints to paper or just to the screen. From Helix’s perspective, previewing a print job is identical to printing it.
Likewise, 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.
|‘Print Posting’ and Client/Server Interaction||
There is a user interaction issue that must be mentioned. Consider this scenario:
In this case, the posting by user B takes precedence. Changes made by user A are discarded when the record is modified by the posting operation. The view is reset to display the values that result from the Print Posting operation. Note that this is true also for Export Posting.
|Can I see where ‘Print Posting’ is used?||
Print Posting is specified by the collection designer, and only Helix RADE has the ability to show this information. In RADE you can use Export Collection Details and look for views that have (#P) at the end of the line; the # is the number of posts attached to that column in the view’s Show Posting mode.
This AppleScript for Helix 6.2 and later examines a collection and generates a report listing the views where Print Posting is used.