8 Replies Latest reply on Jul 21, 2017 8:36 AM by William-Porter

    scroll bars in Windows wreck positioning of unanchored layout objects

    William-Porter

      Context

       

      This bug affects only layout objects that are NOT anchored either to right or left side of the canvas. I have for some time built layouts where NO objects are anchored to port or starboard, so the layout content seems to float in the middle of the page, exactly like this web form in which I'm typing at this moment. It's a terrific design option. Works great in macOS.

      .

       

      The problem

       

      But in Windows 10, if the entire content of the window can’t be displayed in the available vertical space -- if the layout is too tall for the display -- then the scroll bar appears on the right. And the appearance of the scroll bar causes EVERYTHING to get PUSHED TO THE LEFT 17 points. That’s apparently the width of the scroll bar. So if Get(WindowContentWidth) returns 1000 when the scroll bar isn’t visible (say, you’re in list view with only a couple of records found), when the scroll bar becomes visible (because there are more records in the list than can be displayed at once), Get(WindowContentWidth) changes to 983 -- and everything on the layout is moved left to adjust the float, as if the user had grabbed the right edge of the layout and pulled it in to make the window a little smaller. When the scroll bar disappears, everything adjusts back to ‘normal’.

       

      Affects list view AND form view.

       

      This bug makes all my floating layouts jerk around. It’s really a devastating bug for design.

      .

       

      Workaround

       

      None found. Looks like I have only two options: (a) let my Windows users live with things jumping around in a way that makes me look like a careless designer; or (b) start anchoring everything to the left side of the screen. Neither option is appealing.

       

      .

       

      Specs

       

      Windows 10 (with Creators Update), FileMaker 16, on a Dell XPS 15 laptop.

        • 1. Re: scroll bars in Windows wreck positioning of unanchored layout objects
          pjanssen

          I completely agree on this. Having the same problem (jumping of layout when scrollbar visible / not visible), although using Mac OS.

          • 2. Re: scroll bars in Windows wreck positioning of unanchored layout objects
            TSGal

            William-Porter:

             

            Thank you for your post.

             

            If the scroll bar appears, then the width of the window will decrease.  This occurs on both Mac and Windows operating systems.  However, under Mac, if you set System Preferences -> General -> Show scroll bars to either "Automatically based on mouse or trackpad" or "When scrolling", then the window width will not change.  If set to "Always", like it is in Windows, the width will change.

             

            TSGal

            FileMaker, Inc.

            1 of 1 people found this helpful
            • 3. Re: scroll bars in Windows wreck positioning of unanchored layout objects
              hschlossberg

              It's not just a problem for unanchored objects.  I have right-anchored buttons in my top navigation part that now jump around when switching between form and list views.  Since it is impossible to know how wide each user's scroll bar will be, it is impossible to adjust for the difference in my layout design. 

               

              I believe the way this should work is the same as portals, where the width is the width regardless of the scrollbar showing, and a visible scrollbar would simply obscure anything under it.  We can design for that.

              • 4. Re: scroll bars in Windows wreck positioning of unanchored layout objects
                William-Porter

                Thanks for getting back to me, TSGal, and for your informative response. I have three Macs here and I work on all of 'em during any given day but my main machine now is a new iMac, acquired just last week. I don't recall messing with that scrolling preference so I'm guessing it's the default in macOS. And apparently no similar options exist for Windows.

                 

                Okay, so this is the way the operating systems work. Fine.

                 

                But it's still a problem, and it seems to me that since FileMaker controls what is inside its windows, it ought to be able to help here. One of the very best things about FileMaker is that it gives us the ability to create attractive user interfaces. But jerking stuff back and forth (like screen flashing) is NOT ATTRACTIVE. And it's not what users expect from the other best apps they use.

                1 of 1 people found this helpful
                • 5. Re: scroll bars in Windows wreck positioning of unanchored layout objects
                  William-Porter

                  I had not noticed this but Howard's right -- it affects objects anchored to the right as well as unanchored objects.

                   

                  I bet Howard's suggestion is right on the money: it should work the way portals work.

                   

                  I hope this is human nature (and not just proof of what a solipsist I am) but now that I've noticed this myself, I'm shocked that this is the case and amazed that there hasn't been a clamor in the past for this to be fixed. I never noticed it until recently because I have not done any development or testing on Windows until earlier this year. Responses here from TSGal and psjanssen have shown me the problem CAN occur on Mac, and I've now tested that too. So I might have noticed it on Mac but didn't and my guess is that's because, by default, this is NOT a macOS problem. So I'm starting to wonder if there aren't more FileMaker developers working on Macs even than I realized. Plus, when you're working on Windows, you have larger problems to gripe about. <rimshot>

                   

                  Joking aside, this is a serious design issue for me, for my users, and really should be for all those who care about how their solutions look and behave. Hope it can get added to the "Fix ASAP" list.

                   

                  Will

                  1 of 1 people found this helpful
                  • 6. Re: scroll bars in Windows wreck positioning of unanchored layout objects
                    TSGal

                    William-Porter and hschlossberg:

                     

                    Thank you for your comments and observations.  Your posts have been sent to Development and Testing to consider circumventing the operating system scrollbars as part of the window size.

                     

                    TSGal

                    FileMaker, Inc.

                    • 7. Re: scroll bars in Windows wreck positioning of unanchored layout objects
                      TSGal

                      All:

                       

                      Our Testing department is able to reproduce the issue in FileMaker Pro 16, and also mentions the issue does not occur in FileMaker Pro 15.  All information has been sent to Development for further review.

                       

                      TSGal

                      FileMaker, Inc.

                      1 of 1 people found this helpful
                      • 8. Re: scroll bars in Windows wreck positioning of unanchored layout objects
                        William-Porter

                        Well, well. Interesting that it didn't occur in 15! As I said, I only noticed it recently when I started doing some development and testing in Windows 10 with FileMaker 16.

                         

                        Glad they've reproduced it and hope they can get 16 to behave itself again. :-)

                         

                        Thanks for the follow-up!

                         

                        Will