Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Calculating current and total pages accross two layouts


Mad Russian
 Share

Recommended Posts

I have a report that prints from two layouts. The first is a summary section, which can be a max of 2 pages. The second is a report body, which can be up to 10 pages.

 

I want a footer that shows page x of y correctly when the two layouts are printed. I know I could have section one on a Body part and section two on a subsummary part and the page x of y would be easy. Because of a constraint on the user interface, I am not able to take that course.

 

I tried a calculation GetPageNumber + TotalPagesSection1 + 1 to set the starting page in Section2 to the appropriate number (either 2 or 3), but this added the same constant to the total number of pages across the two sections. In other words, if section one was only 1 page and section 2 was 2 pages and I used my global calculation, I ended up with page 3 of 4 in the footer of my last page.

 

Any ideas on how to solve this problem?

 

Thanks

Link to comment
Share on other sites

This program is called Report Writer. It is intended to assist therapists in writing diagnostic reports for client families and their referring physicians. Users of the program find that report writing time is cut in half, at least.

 

The user creates a report with two sections. A separate field is defined for each section, SUMMARY and BODY. Boilerplate text (stored in several global text fields) is brought into the SUMMARY and BODY fields via Set Field script steps. After the SUMMARY and BODY fields are initially populated, the user is allowed to edit each section in Browse Mode.

 

The diagnostic summary intended to be one page in length but allowing up to two pages. The intended reader of the summary section are pediatricians. It is more technical in nature.The diagnostic team signature block is at the end of the summary. Section two is the body of the report with considerable detail but avoiding technical jargon.

 

In beta testing, using a Layout with a BODY part (Summary Section) and a trailing SUBSUMMARY part (Report Body Section), the users enter Browse mode to edit the report. Users found it anoying to typically find a blank page after the first page of the summary section. The user would have to scroll down to find the beginning of the first paragraph found in the Subsummary part.

 

My workaround was to create separt layouts for each section and allow the user to choose to Edit each section in turn (after first previewing the Summary and Body sections).

 

It was at this point that I was faced with the page x of y problem.

 

Thanks for your initial response. I hope this clarifies my ZADACH (problem).

 

Mad Russian

 

PS: A second issue I noticed today is that the program slows down considerable when the user edits the SUMMARY and BODY fields in browse bode?

Link to comment
Share on other sites

Hi

 

I'm not really sure I fully understand. But it sounds to me that you are trying to solve two problems with one layout:

- user data entry / modification

- printing / viewing for different kinds of users (general / pediatrician).

 

If I understand correctly, the layout in question consists of a few large fields (plus maybe some smaller ones with patient names/dob etc).

I think you should do two things:

- use separate layouts for data entry and for printing.

- use separate layouts for data entry of the BODY field and of the SUMMARY field (since they're so large). Fit them out with a scroll bar. Switching between layouts is just one mouseclick.

 

Now you're free to make a print from just one layout without undue scrolling by users.

 

hope this helps

 

kjoe

 

PS edit: I wonder what "boilerplate text" is. the english language is full of colorful metaphor. but I have only a vague idea what it might mean. if I am correct, it may point at a possible solution for the slow editing of the fields. vertel het mij alstublieft (please tell me) :)

Link to comment
Share on other sites

Thanks for your patience:

 

Boilerplate text is a term borrowed from the publishing industry. It is a paragraph or paragraphs of text that tends to be repeated nearly verbatim across many, in this case, diagnostic reports. To borrow an example from my program, "The purpose of this evaluation is to determine if CHILD is eligible for early intervention services based on certain developmental delays or a medical condition associated with a significant risk of future delays..." I work in a non-profit healthcare agency that provides free services to families with "eligible" special needs children. In my program CHILD would automatically be substituted with the First and Last Name of the CHILD. Other Boilerplate in Report Writer would need to be edited to add information indvidual to the particular client.

 

I have a large number of global boilerplate "paragraphs" that may be imported into the SUMMARY and BODY fields based on the writer's choices (scripted buttons). Each of these PARAGRAPH fields are populated through SetField script steps and each can be edited on their separate layouts - as you suggested. These individual fields are accessed using FMP8 tabbed layouts. Editing these separate fields on separate layouts did not present the problem of slow performance.

 

Many of my users are older professionals not very comfortable with computers or software. These folks were uncomfortable editing these separate layouts without then previewing/editing/printing the report as a whole. They wanted to make final edits to the whole report directly. It was at that point that I created the SUMMARY and BODY fields and had the separate PARAGRAPH fields populate these two sections. (The BODY had to start on a new page when printed). When entering Browse mode to edit these two fields containing large amounts of text, I noticed the speed problem. (Is my wife correct? Size does matter?).

 

Wait! You have given me the solution to the page x of y problem. If I crease a separate print layout with Body and Subsummary parts this problem is solved.

 

Do think there is any solution to the slow speed problem?

Link to comment
Share on other sites

hi

 

thanks for explaining. nice to pick up new idiom. Well my thoughts went a bit in that direction and my solution rather hinged on the idea of edit first, concatenate later. But this road seems to be closed.

 

a possible solution might be to use 'export field contents' script step. You can use it to create a .doc format document that will auto open by msWord. it will give you more speedy word processing but the ramifications are

- you'll lose any text formatting (at least, that is my experience so far)

- your users will have to get used to creating the report in filemaker, then doing final edits in the word doc. for you this raises the issue that these edits will not be part of your database; while on the other hand it is not difficult to keep track of the word docs using a container field to store it in.

 

there is a plugin that claims fixing the formatting issue called EZxslt.

 

I hope this is of some help.

 

kjoe

Link to comment
Share on other sites

smiley-smile

 

You have been very helpful. I will check out the plugin. In the meantime, I have fixed the speed problem (somehow?) when I changed some of my script steps and created a separate Print layout.

 

Happy... Mad Russian

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use