What Version of FileMaker are you using? FileMaker 12 has some bugs that can, in certain circumstances, keep slide/resize settings from working.
I'm using version 11. I guess a bit more detail couldn't hurt. There are three fields in the body. The first is a merge field. I am using this because the amount of text in this field can vary quite a bit, so I want it to be able to shrink. Below this are two regular fields. One is a date, and the other is a checkbox that is either Yes of No.
Ok, then FMP 12 bugs with repeating fields and sliding aren't an issue...
Is the data from the merge field the only thing in that text block?
Are there any other objects in the layout body besides these three fields such as a graphic object? (Such as a horizontal line across the bottom of the body layout part?)
Screen shots of your layout--in both layout and preview modes, may help reveal the issue. If you upload a layout mode screen shot of your layout, first select "Sliding objects" from the View | Show menu.
I used to have a horizontal line (which was sliding up correctly), but I took it out in case that was the problem, but it still didn't work.
I am now experiencing stranger behavior. I created some dummy entries to demonstrate the problem, because I cannot release the information in the real entries. However, the problem is not occurring in the dummy entries. As far as I can tell, there is no material difference between the real entries and the dummy entries. The only thing different is the text contained in the fields.
Now my head hurts.
Well. I just made some changes and figured out the difference, but I don't know how to fix it. In my dummy entries, the text ended with a period. In the actual entries, the text ends with a single return. I would understand if this caused an extra line of white space, but it appears to be preventing the body from resizing at all.
I'm guessing there would be a way to make a calcualtion field that would remove any new lines at the end of the text, but this behavior still seems troubling.
The return would add a blank line below the last visible line of text, but it shouldn't keep the field from "resizing at all".
Why is there a return at the end of the text?
This is something that could be removed from these fields fairly easily.
I wans't the person who originally populated these fields, so I don't know why there is a return at the end. It wouldn't be too hard to remove the returns manually, but I generally won't be the one entering this data, so I'm worried that this will continue to occur. I'll look into validation to see if there is a way to prevent it.
As to the effect of the return, I closed the program and reopened it and now I can't recreate the behavior from before.
Now, it seems that the error may not be a resizing problem, but rather a page break issue. It seems that Filemaker may be determining where page breaks should occur before it resizes the body. The result is that if two records would be longer than one page before resizing, then they are put on seperate pages, even if they would easily fit on a single page after the body is resized.
Also, selecting "Allow part to break across page boundaries" does not help.
Well I figured out a fix, but it isn't ideal. When I make the total height of the body with the footer and the header shorter than 8.5 inches, everything works. However, this is not ideal, as it is possible that I could have an entry that would be longer than one page, and making the height less than one page would cause the text to get cut off. Is there a workaround for this.
Also, while I am not observing the issue with new lines anymore, I swear that removing a new line and adding a new line was fixing my problem before. Maybe I was just below 8.5 inches, and the new line was pushing me over the edge.
Ok. I know that I have had a lot of thoughts on what went wrong, but I think I have identified the culprit. Maybe. For one of my "Sub-summary when sorted by" I had both "Page break before each occurence" and "Restart page numbers after each occurence" selected. I want this behavior, however, it appears that the page break was being inserted and the page numbers were being restarted even when there was not a new occurence of this sub-summary part. It seemed to work correctly sometimes, but not other times.
You are also revealing new details about your layout design as you go...
An easy way to remove all the returns from the last character of this field for your existing records:
Make a back up copy of your file (just in case you make a mistake)
Go to a layout where this field is visible/accessible
Select Show All records
Put the cursor in this field.
Select Replace Field Contents from the Records menu.
Use the calculation option with this calculation (use your field names in place of mine):
If ( Right ( YourField ; 1 ) = ¶ ; Left ( YourField ; Length ( YourField ) - 1 ) ; YourField )
An auto enter expression you can use to automatically remove this character for all new records when they are created/edited:
If ( Right ( self ; 1 ) = ¶ ; Left ( self ; Length ( self ) - 1 ) ; self )
and clear the "do not replace existing values" check box.
I think you are running afoul of a known bug, let me check the DB...
For More Information see: Frustrating subsummary bug
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip
Thank you very much. The thread you referred to suggested setting the subsummary part to slide up as well, and this fixed my problem, though apparently it is still considered a bug. Sorry about revealing information over multiple posts, I forgot about things.