4 Replies Latest reply on May 10, 2012 9:42 AM by CICT

    Layout woes

    CICT

      To share our first observations of the new layout tools in FMP 12 and apparent issues we're experiencing on a FMP 11 converted database, the layouts being our own styles.

       

      First minor annoyance was trying to restylise a field formatted as a pop-up menu, but it seems as if we've the Henry Ford policy of a drop shadow colour being any colour as long as it's black - even with newly created fields with line set to None. Gave up on this and moved on to portals.

       

      The first portal is now formatted as 'drop shadow' in the line format menu, but no matter what line/colour combination we change this to within the insepctor, it reverts to 'drop shadow', or at times the line format menu is completely blank. To play safe, we decided to replace existing portals with new ones created in v12. Having created the first new portal to the same size as the original, we positioned this to the right of the existing in the 'working area'.

       

      We tried to move the fields and headers to the new portal. Selecting these was an art, as the new selection method selects any object it touches including background objects, so we spend time deselecting these, before we discover the 'command' drag option that selects as per previous versions.

       

      Now we've got the correct fields and headers selected, we can no longer set the left/top position for these due to the way position works for multiple selected objects. Next step was to temporarily group these to set the new location. However, we now get the 'Objects that are not in the same tab panel or portal cannot be grouped together' message, so we decide to leave the headings alone, move the fields to the right, delete the old portal, then move everything back on the main layout.

       

      However, using Position to place the grouped fields in the correct relative position appears to put them behind the new portal, except they aren't, they just seem to disappear into the portal somewhere, never to be seen again. Further tests without the portal shows that fields within a layout set to coordinates in the 'working area' using position disappear, although if you do a select all you can see their outline. Expanding the layout to the right doesn't bring them back. Dragging fields to this location works fine.

       

      Reverting the layout we try again by dragging the fields, which works successfully. Now all we need to do is to delete the original portal and move the new portal/field combination to the correct location. Oops, can't use position settings on multiple selected objects, must group the grouped fields and portal or drag again.

       

      We do appreciate that this is version 12.0, but do worry about some of the revised techniques that have been introduced. We don't want our databases to look like everyone else's using standard themes. The solution described above has 107 layouts to resolve, but our biggest concern is that we work frequently on RDP remote systems and rely heavily on selection and position techniques, as dragging objects can result in long 'hour glass' pauses while screen redraws try to catch up.

       

      We are continuing to convert existing solutions to FileMaker 12, albeit slowly!

        • 1. Re: Layout woes
          Stephen Huston

          One trick to keep in mind when moving a single object (or grouped objects) onto a portal or tab area:

           

          Positioning via the coordinate numbers in the Inspector can result in the object which was moved not linking to the underlying object, be it a portal or tab.

           

          To resolve this, reselect the obect and move it by dragging or with the arrow keys, even one click up or down in position. That will link it correctly to the underlying containing object. This appears to be a bug.

           

          In your case, you fixed it by dragging, but this will be a problem each time you try to position something over another object if you rely entirely on the inspector  for positioning. Remember to reposition it manually or with the arrow keys after reselecting, and then all behaves correctly again.

           

          Lots of work arounds, changed behaviors, and some new features (bugs?) such as this positioning issue.

           

          Our in-house business solution has over 1500 layouts across 68 files. Luckily, a straight conversion to 12 appears to have left everything functioning. It's what happens when we need to edit them that makes my head spin. (Have you tried changing the text color or size on a converted button?)

          • 2. Re: Layout woes
            CICT

            Thanks Stephen

             

            The interesting thing about moving a field using position to the working area outside of the layout boundary is that it disappears even if it is the only thing that's in this area - no portals, no tabs, nothing. We haven't spent hours on this, so hopefully someone with more time can shed more light on this, but we've found if you do a select all, it gets selected. However, if you try to drag or click in the area of where the field has been put, it cannot be selected.

             

            If you select all, then delselect everything on the main layout, then use the position value to place it back on the main layout it does reappear. In this case you cannot drag it back on though.

             

            Very peculiar behaviour.

             

            p.s. I hate the pts to 3 decimal places!

            • 3. Re: Layout woes
              Stephen Huston

              I have to agree with you completely about three decimal points for positioning. This appears to be done to more accurately position things when they are supposed to be distributed across an area which won't divide evenly among the number of items being ditributed. It's only going to matter on the iOS devices with higher resolution than most desktops, to allow more accurate spacing. (I still deal with hand positioning issues when distributing stuff across a space and find that I can see the 1-pixel differences between some objects.)

                ...but it's going to take some getting-used-to.

              • 4. Re: Layout woes
                CICT

                OK, having spent more time with FMP 12 I now understand that the majority of our woes have been due to working on an FMP 11 converted file. There are certain things that you just cannot change from within a converted file.

                 

                However, if you use a brand new FMP 12 file, set the styles you want in that, then copy and paste an object into your converted file, you can then copy the style to the legacy objects.

                 

                Bit of a pain, but at least a way forward.

                 

                I'm also going to add this to my more recent post, so apologies to anyone who receives 2 copies of this. However, I also hope it helps someone who has been fighting the formatting battles we have.