Here is what the original table in v11 looked like.
This is a known issue with FileMaker 12.
For More Information see: http://forums.filemaker.com/posts/ea146d9cec?start=1&stop=10#189429
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: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
I've tried all day to figure out a way to create the same type of table. I have even gone as far as to breakout the repeating fields and just have them as independant fields, but even with that, I can't get it to print in a form that will give me the look and feel of the sample above.
Any suggestions on how to achieve the same output?
Ever since Filemaker 3 made related tables and portals possible, I've used repeating fields only for certain very specialized purposes.
It'd take some singificant restructuring of your database table, but a list view layout based on a table where each row of data represents a different record would seem possible here--though I only have two screen shots to go on here when I make that suggestion.
I'm will to restructure things if it will make this work and serve to keep it working better going forward with new versions of FM.
I have been trying to do a list view as you suggest; however, the issue is that each record represents a peice of equipment that can have up to 6 or 8 utility connections. I created fields for each possible connection and put them together in a layout using slide printing to remove the unused fields. (see attached screen shot) This would all work just fine if I didn't need to maintain the table borders so the thing is readable. It's not really the data that is not showing up correctly formatted its how filemaker is handling the borders (see screen shot in next post).
Output when not using repeating fields.
Yes, using side borders and Sliding fields on the same layout is a major pain in the ---- in FileMaker. It used to be we had some clever fixes to get around the issue, but recent versions broke those options for us.
The key to your layout is in proper table/relationship design.
I'm feeling my way forward as to the actual data you have in your DB, but it would appear you have somthing like this:
Project Item -----< Equipment----<UtilityConnections (---< stands for "one to many" )
It could easily be much more complex--possibly with a join table between ProjectItem and Equipment--than this and I'm naming the top level table "project Item" as that is the name in the header of your report.
Using that structure as an example however, you can set up your relationships like this:
ProjectItem::ProjItemID = Equipment::ProjItemID
Equipment::EquipmentID = Utilityconnections::EquipmentID
WIth that structure, you can set up a list view layout based on Utility connections and can include fields from Equipment and ProjectItem as needed due to the relationships I've specified. Then a single row in the body of your report represents one Utility connecction. Unused utility connections do not exist and thus no sliding is needed to remove space set aside for connections not needed for a given piece of equipment. As an added benefit, should you receive a new piece of equipment that needs 12 utility connections, you are now able to document it without needing to update your repeating fields and layouts to account for th extra connections. (One of the reasons I avoid repeating fields.)
As long as the fields that make up your single row in the body do not have to slide, your side borders now work.
PS. Splitting existing data from a single record into individual records--one for each repetition is very easy to do with the Import Records tool. It has a special option for this purpose that makes such a data migration from one table to another very easy to do.
Sometimes I don't read as much of the posts as I should, which I say before mentioning this.
I've found that selecting the layout section tool: header, body, footer and then using the middle tab of the inspector clicking on the up a down arrows at the top to clear the layout formating type may eliminate some residual conversion gook.
Maybe create a new layout with the classic setting and copy its formating and then apply it to your layout using a copy of the file for testing.
Okay...I kind of thought that was the direction you would lead me. What I was wondering (before i go through the effort) if I have a list view as you have described, it seems like the table formatting will still be a problem. Take a look at the last table screen shot from my post on the 4th, I cant have a static row height because some rows will have lots of text in the "Electical Notes" column and other will not have any. If I set the row to the max condition my report would be 30-40 pages instead of 5 -10.
So, it sounds from your description there may not be a fix for the table if I need to slideprint. Is that correct? I REALLY don't want to have to dump this back to Excel for formatting!
If the report was made from a related table instead of repeating fields a separate record is used for each line of your repeating fields that contain data, then you can adjust the height of the objets in the list row to 10 lines, or 20 liines or xxx lines and then assign the rows to resize themselves.
A single line of text will resize to one line high and a row where one contains 20 lines of text will resize to 20 lines high.
The layout looks strange with objects that might be several pages high, but it can work for you.
Create a test table of a few fields and test this idea.
Thanks for the input Jack Rodgers...but the issue again is the borders that for the overall look of the table. I did a test layout as you described (see attachment) and it looks great on screen in Browse mode. But when you switch to Preview mode to print the result is again unusable. (see next post)
The report in Preview Mode:
The issue here is the borders on the sides of the field that will not look correct when you have sliding fields for more than one column of data. In your last screen shot, I only see one column where you have multiple rows of text.
IF, this is the only field that can contain multiple rows of text. and IF this field is never empty, you can set your fields to slide and the borders will be where you need them to be.
Since this field is empty much of the time, you can still get borders that work with a bit of creativity. Remove the bottom and side border settings for this field. Enable the side borders on the fields to either side of the field. Enable the top border for this field or put a horizontal line in place for the bottom border and set it to slide up and resize, but extend the lines wider than the field so that they will slide up to the bottom of the fields to either side when the field in question is empty.
Scratch that last suggestion. It won't work. Only option that comes to mind is to do without the side and bottom borders to your field. Add a horizontal line below your fields and set them to slide up, but you'd have to rely on "white space" to separate your columns of data.