5 Replies Latest reply on Sep 6, 2012 10:48 AM by steve_ssh

    Sliding objects in FM GO 12

    DavidZakary

      I'm creating an interface for FM GO 12 and would like to have objects move based on the orientation of the iPad. I'm using a rectangle to hide things.

       

      Currently I have a rectangle that is fixed right. When the iPad is in landscape mode I want to have it slide right and uncover a portal on the left side of the screen. The rectangle does move but it does not want to cover the portal. The portal always remains visible. I've played with the layering and all seems to be correct in that sense. The rectangle does cover the scroll bar of the portal but nothing else.

       

      Am I missing something? Is a portal always a "top" layer? I was sure I had this working before. Now I'm doubting myself.

       

      It works fine in FileMaker Pro Advanced 12 on the desktop.

        • 1. Re: Sliding objects in FM GO 12
          steve_ssh

          Hello David,

           

          Though it doesn't look like there's been any resolution to it, there does seem to be a similar thread which would indicate that you are not alone:

           

          https://fmdev.filemaker.com/message/89538

           

          Perhaps when you had it working before, it was in version 11?

           

          In any event, it does appear as though certain objects layer to the top in Go 12, despite efforts to make them not do so.

           

          Best,

           

          -steve

          • 2. Re: Sliding objects in FM GO 12
            BenGraham

            Hi David,

             

            Yes as you can see from Steve's link this issue has been brought up by myself with FM.  Unfortunately it has not been resolved.  I even find that fields and buttons below the sliding object will function even though they are not visible.  This problem is did not exist with FM Go 11 and in fact was a technique that is very simple and works great.

             

            I have yet to update my solution to FM Go 12 for this reason.  I want to utilize the SQL queries in FM 12 so I may just have to create duplicate layouts and use the OnTimer Script step running every .5 sec to check the screen width and switch to the alternate layout.  I have this implimented for a dashboard with buttons.  I really don't like the OnScript timer method compared to the sliding tab object.

             

            Maybe FM will fix it before I need to ship my new version???

             

            If you find a work around I would love to know it.

             

            Thanks,

            Ben

            • 3. Re: Sliding objects in FM GO 12
              steve_ssh

              Hello Again David and Ben,

               

              It really troubled me that something as elegant as the sliding block technique should compromised in this way.

               

              The optimist in me says that this will be fixed in the next update to FM Go.

               

              The obsessive part of me went exploring for a workaround.

               

              Here's what I considered for a workaround:

               

              If certain types of objects are going to barge their way to the front of the layout order, would it be possible to use one of these very same types of objects to perform the task of obscuring layout objects that are supposed to be hidden for a given device orientation?

               

              In particular:  Instead of using a rectangle object to cover other layout objects, might it be possible to use a giant single row portal?

               

              It is possible.  Certainly it is not as elegant as I would like, but if you are desperate to release something without the OnTimer script, this might be an alternative.

               

              I'll attach a sample file to illustrate the way I went about this.

               

              I think it's possible that someone might be able to take this idea and improve it in some way that I didn't think about, thus turning it into a pretty decent workaround.

               

               

              Speaking of the OnTimer script:

               

              If you are going to go the OnTimer  route, you might look into the possibility of still using the sliding block method, but deal with the portal bleed by filtering the portal based on device orientation.

               

              For example:

               

                For a portal that needs to be hidden when the device is in portrait orientation, add a filter (or modify the existing filter) on the portal such that the filter calculation returns False if:

               

                Get( WindowContentHeight ) > Get( WindowContentWidth )

               

              My reasoning:

               

                With no rows displayed in the portal, there is nothing to enter into or click or bleed through.

               

                I played with this a little bit, and I think there is potential there -- I didn't give it a super-duper thorough testing, but from a little bit of playing with this, it seems to behave as desired.

               

              Except for:

               

                You still need to trigger a window refresh to get the portal to update.  Thus, you still need something (the OnTimer script) to detect and respond to the orientation change.

               

                The advantage that I see to this methodology is the reduction in the number of layouts that one needs to maintain.

               

              - - - - - - - - -

               

              Hope all this makes sense.  Please let me know if I haven't been clear enough.

               

              Kind regards,

               

              -steve

              • 4. Re: Sliding objects in FM GO 12
                BenGraham

                This does indeed sound quite promising Steve.  I had even mentioned in my sample video the fact that the portal I was trying to hide does not "seep" through the sliding block in the area where I had a portal on the sliding block. Only above and below the portal that is on/within another tab, that is on the sliding tab block. Yet I never thought of adding another portal object layer on the sliding block.

                 

                Interestingly the tab that is located on the sliding block tab, has a portal on one tab and fields on the other.  When the tab panel with the fields is selected the "hidden" portal fully displays its fields over the text fields on the layout, yet when the portal tab is selected the "hidden" portal only shows through above and below the portal that resides on the tab.  The portal tab is the default front tab. 

                 

                I have not checked out your attached file yet.  I will give it a look and do a test in one of my files.  I am wondering how the objects above the work around portal object will respond to being "in" or "on" a portal. 

                 

                I can see your point on filtering the portal as another way to hide.  In my soloution I happen to also have dynamic portal filter fields above the portal.  These fields although not visible are still able to be activated if a user touches their location.

                 

                Good job. 

                 

                Warmest regards,

                Ben

                 

                PS- I will let you know how it goes.

                • 5. Re: Sliding objects in FM GO 12
                  steve_ssh

                  Hi Ben,

                   

                  Glad what I'm saying makes sense.  Below are just a couple of extra comments.

                   

                  Very best and good luck,

                   

                  -steve

                   

                  BenGraham wrote:

                   

                  This does indeed sound quite promising Steve.  I had even mentioned in my sample video the fact that the portal I was trying to hide does not "seep" through the sliding block in the area where I had a portal on the sliding block. Only above and below the portal that is on/within another tab, that is on the sliding tab block. Yet I never thought of adding another portal object layer on the sliding block.

                   

                   

                  This is in agreement with what I would expect.

                   

                  I have not checked out your attached file yet.  I will give it a look and do a test in one of my files.  I am wondering how the objects above the work around portal object will respond to being "in" or "on" a portal.

                   

                  In my mind, this is where the extra hassle is with this workaround, that makes it rather clumsy.  If you play with the idea, I think that you will see for yourself.  In short, your objects are now sitting on a portal row (I used a single row portal based on a self join by primary key).  If the content that is sliding to cover and hide your portal were simple (not a bunch of related fields), I think you'd be ok with this idea.  From what you wrote, you have a tab object with another portal sitting on top of it.  I think that might be more than you want to do with this idea -- I believe it would just require you to add too much complexity to make it worth while.  I'm sorry to say that I think that is likely to be the case.  Please don't let my words stop you from trying -- This is also the part of the workaround where I think someone with a fresh perspective could make a tweak to my approach to make it less clumsy.

                   

                  I can see your point on filtering the portal as another way to hide.  In my soloution I happen to also have dynamic portal filter fields above the portal.  These fields although not visible are still able to be activated if a user touches their location.

                   

                  You might try putting these additional filter fields on top of a hidden portal and, similar to how you break the filter on the portal with rows, also break the hidden portal that holds these fields.  To me this seems less complex than trying to put the sliding content that you have (tab object & portal) on top of a sliding portal.  (Just a thought.)

                   

                   

                  PS- I will let you know how it goes.

                   

                  That would be great. I'd love to know...