1 of 1 people found this helpful
From the FMI Knowledge base:
Answer ID: 10261"FileMaker Conversion Checklist"
Buttons and other layout objects to which text has been added may appear smaller in the convertedlayout.
A layout object that’s inside a portal, tab control, or group of objects belongs to the same layout part as the portal, tab, or group of objects. (This does not apply to grouped layout objects without button actions.) For example, if a line is in a tab control that belongs to the header, the line belongs to theheader even if the line appears on the body. If you delete the header, the tab control and all objects in it are also deleted.
If an object spans multiple layout parts, after conversion it will only appear in the part at the top.
If a group of objects spans multiple layout parts, after conversion only objects in the part at the top will appear in Preview mode.
Change in behavior number 3.
Richard, with conditional formatting, some of these old tricks are no longer needed. You can add the sub-summary part, but don't need to add fields to it. Then put the field on the body and conditionally format to show once as needed in a "summary group". (I don't know all that you are doing, so can't be specific.)
Hi Beverley. If this gets around the Hanging fields, that would be great. Can you point me to any walk-throughs or a little more detail? I have an urgent catalogue to set up which has always relied on the "hanging" SS-part feature for image container fields to line up with product codes. Can you explain what you mean by a "Summary Group"?
Yep, it's a known change of behavior, and a very unwelcome one. I used this type of hang-down to tighten up lots of list reports before 12, and have had to rebuild those layouts as I encounter them ever since the upgrade.
Thanks for the redirect Stephen. I noticed this post after I had written my plea elsewhere. When you say "rebuild" do you mean you have a solution, or is it just not possible? My 90 page catalogue is about to increase by 30 or more pages if this won't work at all.
It has worked with hanging fields from early FMP days. Why the change? I feel like I am missing something obvious from reading Beverly's post but don't know where to look. Did her hint suggest any solutions to you?
I feel a panic moment coming on... 1 Mississippi, 2 Mississippi ...
A client just called me saying that a user couldn't see the watermark on a certain layout. The layout is similar to what's being described: it has a tall graphic (company logo with watermark) placed on the header part and extending down and through a leading subsummary part, the body part, and then a trailing subsummary part. Some computers could see it, others couldn't. The ones that couldn't were running FMP 12v1 or v2. Upgraded them to v3 and all is good. I don't quite know what the difference is between this setup and what's being described above, but this certainly contradicts FileMaker Conversion Checklist #3 above and the results of many others. And I can't imagine the developers above aren't running the latest v release of FMP.
Ann Arbor, MI
Hi Gordon, thanks for the info.
I am working on 12v3 (Mac) and I can confirm that unfortunately checklist item #3 remains valid. However if your client has a working version, maybe there is a way around this. I tried to replicate, thinking that maybe it just works in the header and not the SS-part, but I'm afraid not - not on my Mac at least. It looks like their developer has figured out how to do this and I haven't.
Counties Furniture Group
OK, re-read the 12.v3 changelog more diligently and ran some checks and yes, you can use hanging watermarks IF you use the classic theme, so good news for some out there.
The bad news is that this only works for layout images, not images in container fields
I played around with this some more and I found that I can recreate the problem that everyone is talking about. In my db where the overhang works fine (it was upgraded from .fp5 and .fp7), I could recreate the problem if I changed the body part to a color. Any color. When I changed it back to white, all was good. The config was header with overhanging graphic extending onto the body part.
I also created a new db (built from scratch in .fmp12) and could recreate the problem. And using a white body part did not fix it. But changing the body part to no color (the white square with the diagonal red line through it in upper left corner of color pallette) fixed it. Maybe worth trying?
Ann Arbor, MI
I concur. For layout graphics the classic theme will allow hanging images across your other parts. However for images in container fields this will not work currently, although it would be very useful if it would work as it used to for years.
I can understand that for text and numeric data fields there may be good reason for not doing so (although it was still bloody useful) but for image rich FMP solutions which are likely to grow going forwards, this definitely feels like the product is going backwards (image and media storage improvements notwithstanding). If that sound like sour grapes, then I am not putting it strongly enough, my grapes taste like vineagar!
(Thanks for the help btw Gordon).
She is recommending moving the field down so it populates on each row, and then setting a conditional formatting calculation to perhaps change the color of the text and background nothing.
You can use the follow calculation:
Case(DateField ≠ GetNthRecord ( DateField ; Get(RecordNumber)-1) ;0;1)
Thanks for the explanation Christine, I understand the principle and will add some record numbering to my solution and test.
Hmmm...I suspect however that changing the visibilty will not enable sliding, so my spacing per record will remain fixed to the container field size for each record, which will be worse for me than having the image once in the SS-part.
(the advantage for me of the "hang down" method which only meant one summary image hanging over many records was that my blocks of records only had one image with no build up of whitespace).
Of course I can still use a Container field in the SS-Part as previously, I just cannot recover the space below the image as I used to, which adds up considerably over a few thousand items.
I think I have had my chips, as they say in these parts (that's "French Fries" in many other places). I will plead for a change of heart from Filemaker to reinstate this function.