Print Step with scrolling data

I have created a document database housing all procedures with approvals, revisions, release date, etc. It tracks past revisions and also links to a training database that assigns training and allows the user to train. The issue I am running into is printing records/tables. I have the app show a list of all released procedures and will display on the print screen to be able to print a hard copy. In testing, everything worked great, as I was only using a handful of procedures. After loading all the current procedures, the screen populates with the list and has a scrolling feature. My assumption was when it would go to print, it would print multiple pages to show the entire list. I was wrong. This would also now apply to training records.

Is there another way to complete this function?

hello @jquinton, welcome to the Tulip Community!! it would be great if you could introduce yourself at: Welcome to the Community, let's meet!!

regarding your question, there are several ways to solve this. I’ll suggest one here, but I’m curious to hear if users have other suggestions. the basic idea is to create several Table Queries and then paginate the Table data into several Steps that are then included in a Step Group to be printed.

here’s the guide:

  1. add an Index to the data in the Table data:

  2. create Queries that Filter by the Index (depending on how many you’d like displayed):

  3. add the Table Queries to the App:

  4. display the Table Queries in several Steps into a Step Group:

  5. Print the entire Step Group:

result: Tulip Player.pdf (33.2 KB)

let me know your thoughts on this solution!!

Gio@Gio- Thanks for the quick reply!!

I can see how your suggestion would help is the list was static, but unfortunately it will be dynamic. I have it coded to create a new entry when a procedure has a revision. When the revision is submitted, it will inactivate the old revision and activate the new one. I can then sort the list for active procedures for review as well as print out for an auditor. I can also view the entire revision history of a procedure in another query.
I could see carrying over the indexing number and make it tied to a procedure, but if a procedure gets obsoleted or a new one introduced, the indexing would be off.
The complication would get compounded when trying to print the current training matrix for an employee as the printable list would be generated off a query of the individual employee.