14 Replies Latest reply on Aug 11, 2013 9:18 AM by philmodjunk

    Portals and Tab Controls fail to "own" enclosed objects

    philmodjunk

      Summary

      Portals and Tab Controls fail to "own" enclosed objects

      Product

      FileMaker Pro

      Version

      12.03

      Operating system version

      Windows XP, Windows 7

      Description of the issue

      If you use an alignment tool in the inspector to align an object outside the borders of a tab control or portal with an object that is inside and the resulting position change places the outside object within the borders of the tab control or portal, the tab control or portal will fail to "own" the newly repositioned object

      If you drag the portal or tab panel, the object does not move with it. And the object will not display correctly--it will be visible only in the first portal row and it will be visible no matter which tab panel is selected.

      Steps to reproduce the problem

      Put an object inside a portal's row. Put a second object at least partially outside the portal row positioned to the left and lower than the first object.

      Select both objects by shift clicking.

      Click the align top edges and align right edges tools to pull the second object inside the borders of the portal row.

      Now drag the portal to a different position or view it in browse mode to see that it's only in the first portal row.

      Repeat these steps with a tab control.

      Expected result

      The enclosing tab control or portal should own the object. The object should move when the owner moves and the object should display correctly.

      Actual result

      It's not owned. It doesn't move and it doesn't display correctly.

      Workaround

      Place the object inside the boundaries of the portal or tab control. Then use alignment tools to align it to other objects in the portal row or tab panel.

        • 1. Re: Portals and Tab Controls fail to "own" enclosed objects

               PhilModJunk:

               Thank you for the post.

                

               Following the steps provided, I was able to replicate with FileMaker Pro 12.0v3 installed to Mac OS X 10.7.5 and using FileMaker Pro 12.0v3 Advanced installed on Windows 7.

                

               I forwarded a full report to Testing and Development for review.

                

               TSFalcon
               FileMaker, Inc.

          • 2. Re: Portals and Tab Controls fail to "own" enclosed objects
            MikhailEdoshin

                 I second that; the same thing happens if the object is positioned by numbers. The only way to get it to "own" the object is to move the object with the mouse; and this may be very difficult if the object has the same height as the portal row.

                 At the same time it's very easy to "disown" the object; either way works.

                 If this disownment was meant to be a feature (some people try to devise clever widgets around it), it's better to make it explicit, e.g. have a checkbox somewhere in the inspector, a list to select the linked tab, or something like that.

            • 3. Re: Portals and Tab Controls fail to "own" enclosed objects
              philmodjunk

                   @TSFalcon,

                   Can you anticipate my question? Does this also happen on a Mac system or is it WIndows only?

              • 4. Re: Portals and Tab Controls fail to "own" enclosed objects

                     PhilModJunk:

                     Thank you for the reply.

                      

                     As stated in my post above, this was tested both on both Mac OS X 10.7.5 and Windows 7 with the same results. 

                      

                     TSFalcon
                     FileMaker, Inc.

                • 5. Re: Portals and Tab Controls fail to "own" enclosed objects
                  jfletch

                       This has happened to me almost since day 1. I fought with this issue for DAYS when I first found it very early on. I lost many more hours after that until I found a "fix." I found that in addition to Mikhail's solution you can grab all the fields and nudge them down a few pixels and back up with the arrow keys and they will stick. You can test that they are sticking and will display correctly by grabbing the portal with the mouse and dragging it away and back into place. If all the fields move with it, you're good. But I shouldn't have to do that at all!

                       I am STILL not able to get a tabbed object to stay in a single-row portal for the "magic portal trick," though. Very disappointed.

                       Come ON, people! You've had four versions of FMP 12 out now. Can we get this stupid bug fixed? This thing is more than an annoyance; it has cost me serious time!

                       FMPA 12.0v4, Mac OS X 10.7.x - 10.8.3

                  • 6. Re: Portals and Tab Controls fail to "own" enclosed objects
                    philmodjunk
                         

                              I am STILL not able to get a tabbed object to stay in a single-row portal for the "magic portal trick," though. Very disappointed.

                         It was my understanding that tab controls cannot be placed in portal rows.

                    • 7. Re: Portals and Tab Controls fail to "own" enclosed objects
                      jfletch

                           Evidently. Too bad. It's the easiest way to get stuff to show or disappear. 

                           Still, what about that fields-not-sticking-in-the-portal issue? Is that ever going to get fixed?

                      • 8. Re: Portals and Tab Controls fail to "own" enclosed objects
                        philmodjunk

                             As a fellow user, that's not a question that I can answer.

                             Using tab controls to hide reveal objects works well in form view but is problematic in list view--the action to select a tab panel selects it for all the records--not just one so I don't know that such a method would work even if tab controls could be placed in a portal row.

                        • 9. Re: Portals and Tab Controls fail to "own" enclosed objects
                          MikeK

                               I'm sorry, this should be marked much higher than "nuisance". This is an extremely serious bug. I have wasted many hours tonight trying to get a portal to "own" fields ... the whole process seems completely arbitrary. I know how it's supposed to work, but in reality there is no identifiable logic to when objects get owned or disowned, and it's making working on my database impossible.

                               Being able to place fields into portals is a fundamental part of developing for FIleMaker... if doing that simple task takes literally hours to accomplish, I'd go so far as to say FileMaker 12 is just about unusable.

                          • 10. Re: Portals and Tab Controls fail to "own" enclosed objects
                            jfletch

                                 Mike K.: I have made peace with this bug (yes, "bug"), and just accept that my little procedure is part of how to place a field in a portal:

                                 1. Command-select (on a Mac) all of the items on a portal row. 
                                 2. Nudge the items down into the portal with the arrow keys a few pixels ("points," whatever that means)
                                 3. Nudge them back up to where you want them positioned

                                 I have found that this works reliably 100% of the time, so as long as I know what to do that I only have to spend a LITTLE extra time on it, I can live with it. I should not have to, but...

                            • 11. Re: Portals and Tab Controls fail to "own" enclosed objects
                              philmodjunk
                                   

                                        I'm sorry, this should be marked much higher than "nuisance".

                                   I suggest you read the info on "risk level" that is provided at the beginning of the Known Bugs List thread and also on the title layout of the database:

                                     
                              1.           This ranking has a very narrow definition identifying the risk to the data in your database and the file's structure. Bugs that have a very serious consequence for your databse solution will still be labeled "nuisance" if they don't fit that definition. In this case, I can't conceive of any likely result of this issue resulting in a corrupted file or the loss/changing of data in your database as it mainly is a headache for us when we develop the layout.
                              2.      
                              3.           This is my personal opinion as a fellow user. It, as far as I know, has no influence whatever on any priority FileMaker Inc may choose to set on when or if this bug will be corrected.


                                   I will add the following comment on this bug:

                                   Since reporting this, I've created a layout for the IPhone that presents the user with a Calendar. Each square on the calendar is a one row filtered portal that may or may not refer to any actual records. The ability to position a number field for the date in the upper right corner of the portal without it being "owned" by the portal was crucial to the correct function of this layout and I was able to use the alignment tools to "slide" the fields into that position and yet keep them free from portal ownership. Had it been "owned" by the underlying portal, it would have been missing from all portal instances where there was no related record displayed in the portal.

                                   Please note that I am not suggesting that this bug should not be corrected. I've wasted more time than I care to admit fiddling with the "finnicky" aspects of this "ownership" bug. But I am requesting that when they fix it, that there should also be some means of putting an object on top of a tab control or portal so that it is not owned by the portal in order to provide a full range of layout design options.

                              • 12. Re: Portals and Tab Controls fail to "own" enclosed objects
                                MikeK

                                     Well, I have a different definition of "file integrity" than others do, I guess. I would consider anything that randomly and spontaneously renders a layout that I spent hours on completely unusable, making FMP12 a complete impossibility to develop with, a problem with integrity. And make to mistake: that accurately describes the problem I am having. My file has been trashed, hours of work wasted by my solution's main portal's sudden decision that it will not contain any objects under any circumstance, regardless of what I put there or how. My file is 100% unusable now, a complete waste.

                                     And the way this happened? I selected the objects in a portal and hit CMD-C to copy them. That's it. I didn't move them. In other cases, objects that were completely within the portal were nudged a few pixels horizontally, still completely enclosed by the first row of the portal, and then they dissassociated and it took 40 minutes to get it to "own" them again.

                                     I do agree with you that it is nice to have the option - the option, if and only if desired  -  to include object physically in portals without the portal "owning" them, and see the validity of your example. However, in 20 years of nearly full-time professional FileMaker development (since version 2.1), I myself haven't even once encountered a feature that I was unable to implement for lack of this functionality. But adding fields to a portal has been crucial to nearly every filemaker database I've created in those 20 years, and now it is literally impossible, with no rhyme or reason as to when or why I can or can't. This is the very definition of a showstopper bug. I can't believe they actually released this, let alone 4 revisions of it. I am looking at many, many hours of work down the drain, just because I wanted to swap the position of two fields within a portal row. I'm rolling to a backup, and if that fails, I'm going to have to call the client, after many hours of work, and decline the job. I am beyond unhappy with FMI right now, just absolutely livid.

                                     The ability to decide, after a portal is created, that you want to swap the position of two horizontal field in it should not occasion many hours of frustration, and certainly shouldn't all by itself trash a solution beyond all usability. I can't believe this even needs to be said.

                                     Jonathan Fletcher, thanks for the tip, but your instructions didn't solve the problem for me. I have tried every permutation of resizing, dragging, nudging, cutting, copying, and pasting, on the fields and on the portal itself, to try and get the portal to display a field I place within it. Nothing works, the portal will not display anything, regardless of how they are added to it or jockeyed around after adding.

                                • 13. Re: Portals and Tab Controls fail to "own" enclosed objects
                                  jfletch

                                       Mike, my experience was just like unto yours at first: hours and hours of swearing, head-banging, beating my wife, kicking the dog and calling down hellfire and damnation on FMI, all its employees and their children, yea unto the third generation. The technique that I described has returned me to the state of mere babbling lunacy that I enjoyed before running into this bugger. 

                                       It astonishes me that it doesn't work for you. Have you tried [command-drag] selecting all the fields on the row, moving them off and back on and then applying the nudge down and back up? Including in there somewhere moving them all to the front?

                                       I haven't had a problem with this for months unless I forget to apply the "magic ingredient."

                                       I haven't let the FMI employees' great-grandchildren off the hook yet for the other abominations introduced in the layout mode of FM12, but the veins no longer pop out of my forehead when putting fields in portals.

                                  • 14. Re: Portals and Tab Controls fail to "own" enclosed objects
                                    philmodjunk
                                         

                                              I have a different definition of "file integrity" than others do, I guess.

                                         Can't speak for others, but yes, your definition differs from mine... Damage to file integrity in my lexicon is a corrupted file, not a single layout that doesn't work the way I expect it to do. And please keep in mind this is just an opinion on something that can indeed be very subjective.