6 Replies Latest reply on Jul 20, 2013 2:53 PM by LaRetta

    Go To Object  Unexpected!

      Hi everyone,

       

      Almost every day, I see potentially dangerous uses of scripted Go To Object[] particularly ( but not exclusively ) when used with tab controls. Even skilled FM Developers can be bitten by this unexpected behavior.

       

      I just posted an example over on FMForums but not all of you frequent that forum so I thought I should post here as well. My apology that I haven't had a chance to post this sooner.

       

      http://fmforums.com/forum/topic/89095-go-to-object-unexpected/

       

      There is a simple sample zip for version 11 and 12 which ( hopefully clearly ) walks through the issue for you to see it happening. I also throw out my theories on explaining the behavior but I might be wrong so I am open to correction and input.

       

      Thank you!!

        • 1. Re: Go To Object [ Unexpected! ]
          Malcolm

          What's the difference between

           

          go to object[A]

          and

          go to portal row[last]

          and

          go to layout

           

          Each will go to the thing described it doesn't care where it is right now. It just goes to the thing.

           

          Go to Portal row was always flaky because there was no way to specify the portal.  It is now possible to name objects.

           

          If you want to display a tab then you can name the tab and use go to object[].

          If you want to go to a portal you can name the portal and use go to object[] or you can name a field within the portal and go to it.

           

          mal[colm

          • 2. Re: Go To Object [ Unexpected! ]

            Wow.  I failed at being clear enough in my demo, right off the bat, Malcolm? 

            Malcolm wrote:

             

            Each will go to the thing described it doesn't care where it is right now. It just goes to the thing.

             

            Go to Portal row was always flaky because there was no way to specify the portal.  It is now possible to name objects.

             

            If you want to display a tab then you can name the tab and use go to object[].

             

            My point is that I see Developers every day making script-step suggestions as in my demo.  And I see newbies with the same scripts.  And using those script steps in that way is not safe.  You say it just 'goes to the thing' ... well, no, it doesn't always which is my point.     ... well yes, Go To Object[] Isn't the culprit here - only how it is used improperly.

             

            I am attempting to provide an example of this mis-use and a principle of naming portal or naming field to guarantee ending up in the right place and NOT relying on naming a tab then using Go To Field[] or Go To Portal Row [ Last ].  In addition, understanding layout stacking order versus tab control stacking order is important as well. Thanks for the input - I'll review the demo to see if I can make it clearer.

            • 3. Re: Go To Object [ Unexpected! ]
              steve_ssh

              Hello LaRetta,

               

              Thank you for taking the time to post this in the TechNet forum.  I'm going to take a look and see what I can learn from your demo.

               

              Thanks and kind regards,

               

              -steve

              • 4. Re: Go To Object [ Unexpected! ]

                I just realized FMForums isn't allowing downloads of sample files unless someone is registered. I am hoping they will fix it.

                 

                So for folks, I will attach here as well.  Do NOT discount this simple, easy-to-understand file which will take you three minutes to review (you must be signed in to download, sorry).  And I could not figure how to make the file any simpler or clearer than it is and it is in 11 and 12 format both.

                 

                Hey Steve, thanks for responding ... it is appreciated.

                • 5. Re: Go To Object [ Unexpected! ]
                  debi

                  LaRetta,

                   

                  Years ago, through tedious testing and debugging, I came to what is more or less an SOP for my current work:

                   

                  Script to add related record in portal without auto-creation:
                  Grap parent ID
                  New window
                  Go to child context
                  Set foreign ID for parent
                  Grab child ID
                  Close child window
                  Go to object <- named field in portal, whichever field I expect user to start typing in
                  Go to first row
                  Loop
                  Exit loop if child ID = child ID grabbed earlier
                  Go to next row
                  End Loop

                  Go to object <- same named field in portal as earlier

                   

                  The looping takes care of any sorting that may move the new record due to auto-entered values, as well as the odd possibility someone else is adding child records at the same time.

                   

                  I used to feel a little silly going to the named object more than once, but your demo really helps explain the WHYs that I never took the time to figure out before.

                   

                  THANK YOU!

                   

                  Debi Rubel
                  FullCity Consulting

                  • 6. Re: Go To Object [ Unexpected! ]

                    Thanks, Debi. 

                     

                    I was quite surprised at the difference in stacking order on tab controls versus base layouts.  I would have thought stacking order would be based only upon the order of objects placed on the layout and tab control would follow same premise.  But tab controls must sit on a higher layer so they are evaluated after all base layout objects, even objects placed onto base layout later. 

                     

                    And further, tab control's stacking order is always panel order (with stacking order within a single panel) and order of placement of objects onto the various tab panels makes no difference which goes against our my previous understanding of stacking behavior.