11 Replies Latest reply on Nov 24, 2009 5:45 PM by DLW-BPEX

    Header and Body conflicting



      Header and Body conflicting


      Header from 0 to 50 vertically. Body from 50 to 600.

      Object on the body, extending from 50 to 100.


      Under Mac OS X, no problem.

      Same db file under Win XP, SP2: Object shows fine in Layout mode. But it disappears back in Browse mode. If I move the object down 1 pixel (to start at 51), it is okay under Win XP, too.


      Strange? Normal? Is it necessary to avoid putting anything at the very tippy-top of a Body to appease Windows for some reason? Or in general, to avoid Part-Finish and Part-Start with the same pixel locations?

      Am I seeing some sort of anomaly?


      This is with FMP10 Advanced.


      Thank you.


        • 1. Re: Header and Body conflicting


          Header 0 to 50 and body 50 to 600 can not be.

          Header 0 to 50 and body 51 to 600 can be.

          Object is 50 to 100, it is on the header. 

          • 2. Re: Header and Body conflicting

            Thank you, David.


            When I create a new layout, FM defaults to:

            Header = 0-18

            Body = 18-252

            Footer = 252-270


            I am not sure where these default values are coming from, but it does seem to indicate that Part-Finish and Part-Start can be the same pixel(?). I have been doing this for awhile under Mac OS X and just happened to notice the problem recently under Win XP. 

            • 3. Re: Header and Body conflicting

              In spite of what the Object Info palette may say, no pixel of the layout can be part of two layout parts. If an object has even one pixel that is located on the header, the entire object is treated as part of the header (and this is true of other layout parts as well.)


              I haven't noticed any platform differences here, but then I don't have access to a Mac OS system at this time.

              • 4. Re: Header and Body conflicting

                A little more playing around with this showed something interesting:

                Under Win XP in browse mode, only the portion of the object not extending off the bottom of the header gets displayed.

                Under Mac OS X, the entire object shows up, with no obvious indication of which part it is on.

                In both cases, of course, deleting the header loses the object, too.


                Developing on a Mac for cross-platform use, the significance of this is:

                Let's say an object is in the body of a layout that has no header, and the object is at 0,0. If I later insert an 18-pixel header using Insert > Part > Header, the body and its objects are moved down. The body starts at 18 (and header ends at 18). The 0,0 object now starts at 0,19. All is good.


                But inserting a header by dragging the Part icon does not move things down. Instead, the header "steals" vertical area from the body, whose size shrinks accordingly. Any objects falling slightly within the bounds of (or touching) the header are now transferred to the header. Under Win XP, this would be apparent back in browse mode. Under OS X, not as apparent.


                Does this sound right? Seems a little dangerous. Are there times when it would be desirable to create a header by dragging? Maybe to add (rather than insert) a header and maintain overall layout size?


                Thank you.


                • 5. Re: Header and Body conflicting

                  I'm using windows XP and I cannot duplicate what you describe: "only the portion of the object not extending off the bottom of the header gets displayed."


                  I opened one of my test DB's


                  I moved a field up until the top pixel was on the Header/Body border making it part of the header.

                  I entered brows mode


                  The entire field was visible, displaying the contents of that field for the current record.


                  Keep in mind that header fields display the contents of the current record in browse mode and the first record when in Preview.

                  • 6. Re: Header and Body conflicting

                    I had a Fill specified for the body. It seems that covered up any parts of objects that were overflowing the header. In Win XP, that is. With OS X it made no difference; the entire object is visible whether or not the body has Fill.


                    FWIW, my Win XP is running under Parallels on a Mac. I doubt it makes a difference, but who knows with different drivers.


                    At any rate then, it seems that under either platform one could end up with body objects moved to the header without realizing it.



                    • 7. Re: Header and Body conflicting
                         That's the difference. When I went back and assigned a fill color to the body, I could make the field appear/disappear by clicking on different records and fields. I think this qualifies as a bug as a part's fill color should not affect layout behavior in this way.
                      • 8. Re: Header and Body conflicting

                        Yes, changing records makes the field appear entirely. Then clicking on the field itself hides the overflow portion again.

                        I guess the other issue is more worrisome, though: Possibly having objects move from one layout part to another without realizing it. That one probably is not a bug, though. Just something to be careful around.

                        • 9. Re: Header and Body conflicting
                             Something to be careful about, but not too difficult to avoid once you're aware of the issue. With experience, it's pretty easy to identify and correct when it happens.
                          • 11. Re: Header and Body conflicting


                            Glad to see you reported it since you obviously are much more experienced than I.


                            It still bugs me (pardon the pun) that if you want to position an object in the upper-left of the body (e.g., a navigation button bar), you must keep in mind whether or not there is also a header. If you have a header 18 pixels high, the body starts at 0,18. Yet the object must start at 0,19 to avoid being assigned to the header. But if no header, the body starts at 0,0 and so can the object. (If you do the same 1-pixel drop, you will have an annoying 1-pixel bg strip.)

                            Not very intuitive to me. Intuition would say that if FM says the body starts at 0,18 and you want an object in its upper-left, you position the object at 0,18. (And actually, FM does dictate that the bottom pixel of the header is also the top pixel of the body -- at least as indicated by the Object Info box. Referring back to David Anders' initial response, it is not what happens. If the header is 0-50, the body WILL BE 50 to whatever. The user can do nothing about it.)


                            Once you have correctly positioned the object at 0,19 (if a header exists), should you later decide to delete the header, the body moves to 0,0 and shrinks by a pixel. The object magically jumps to 0,0 also.

                            Of course this applies similarly to the bottom of the layout.


                            There no doubt was some design rationale behind this. So I wouldn't consider it a bug, but a flaw.



                            Oh, well. Sorry for the mini-rant. But it definitely has given me a new appreciation for the importance of that one little pixel.


                            As always, thank you for your clear and patient guidance.