10 Replies Latest reply on Jan 20, 2014 10:38 AM by fred@kca-inc.com

    Maintain Portal Row Visibility

    fred@kca-inc.com

      Title

      Maintain Portal Row Visibility

      Post

           I have a layout with a portal.  I scroll down the portal and select a record.  Then a script freezes the screen and goes to another layout to do some calculations.  Then I return to the original layout with the portal and the portal resets the view to the top rows.

           Is there some magic way to maintain the previous view of the portal when I come back to it?  I can scroll down in script, but it's difficult to get the same row in the same position on the screen.

        • 1. Re: Maintain Portal Row Visibility
          philmodjunk

               There is no "magic method". The layout change resets the portal scroll bar. You could save the current portal row to a variable and then use go to portal row to reset the focus on the portal row. This makes the portal row visible, but it may not be in exactly the same position as it was before you performed your script. Sometimes that's the best you can do with FileMaker.

               But what "calculations" is your script doing? Perhaps there is a way to do what you need without actually changing layouts.

          • 2. Re: Maintain Portal Row Visibility
            fred@kca-inc.com

                 Thanks for the feedback.  I created a short script to put the portal row in the vertical middle of the portal (attached)

                 The script works great again in the Script Debugger.  When I run it in normal mode, the selected row ends up at the bottom of the portal.  It's tough to troubleshoot these types of issues when the Script Debugger provides different results than the normal run mode. Is this something I should turn in as a bug?

                 I looked at the script to see if I could not switch off the layout.  Unfortunately, there are 2 related tables (both related back to a master table).  The script has to be able to insert records into either of the tables in portals.  The New Record script step wants to insert into the master table that the layout is based on instead of the tables on the layout.

                  

            • 3. Re: Maintain Portal Row Visibility
              philmodjunk

                   Ever since I realized the problems inherent with the Change layouts, make a new record, change back script, I've been thinking about this one and have an alternative approach that successfully creates new records in related tables without having to change layouts. Not only can you have this problem with the portal, but the script can trip script triggers on either of the two layouts and if you are doing this in FM GO, a phone call at the wrong instant can leave the user on the other layout.

                   Let's start with the typical one to many relationship required for the typical portal:

                   Parent----<Child

                   Parent::__pkParentID = Child::_fkParentID

                   Now define a new field in Child as _fkParentIDCreate

                   Make a new Tutorial: What are Table Occurrences? of Child, name it Child|Create and add it to your relationships like this:

                   Parent----Child|Create

                   Parent::__pkParentID = Child|Create::_fkParentIDCreate

                   Enable "allow creation..." for Child|Create.

                   Use this script to create a new record in Child:

                   Set Field [Child|Create::_fkParentID ; Parent::__pkParentID ]
                   #Put any other set field steps you need for putting data into the new record here
                   Set Field [Child|Create::_fkParentIDCreate ; "" ]

                   The last step is crucial. It disconnects the new record from the Parent to Child|Create relationship so that this script can be used to create another new record the next time it is run.

                   You may need a commit records or Refresh Window step here in order to get your portal to show the new record.

              • 4. Re: Maintain Portal Row Visibility
                fred@kca-inc.com

                     This is cool.  I may be able to get rid of a bunch of extra layouts (which are there for nothing other than creating records) using this technique.  Please help me understand a few things:

                     Because this relationship exists: Parent::__pkParentID = Child|Create::_fkParentIDCreate, doing the Set Field [Child|Create::_fkParentID : Parent::__pkParentID ] forces the child table to create a new child record with the _fkParentID inserted?

                     doing the Set Field [Child|Create::_fkParentIDCreate ; ""] just empties the field for the relationship in the Child table?  The join stays in tact, but the relationship to that record does not exist with the empty _fkParentIDCreate field?  This, then, would allow the creation of another child record to the same parent record?

                     Does the _fkParentIDCreate field have to be populated?

                      

                • 5. Re: Maintain Portal Row Visibility
                  philmodjunk
                       

                            Because this relationship exists: Parent::__pkParentID = Child|Create::_fkParentIDCreate, doing the Set Field [Child|Create::_fkParentID : Parent::__pkParentID ] forces the child table to create a new child record with the _fkParentID inserted?

                       Yes, but only if "Allow creation of records via this relationship" is enabled for Child|Create.

                       

                            doing the Set Field [Child|Create::_fkParentIDCreate ; ""] just empties the field for the relationship in the Child table?

                       It does exactly what you see. It assigns an empty string "" to the _fkParentIDCreate field clearing the ID from the parent record that is automatically entered when the record is created by the first set field step. Since this is the match field linking the new record to the parent record in the Parent to Child|Create relationship, this severs the link between these two records.

                       

                            This, then, would allow the creation of another child record to the same parent record?
                            Does the _fkParentIDCreate field have to be populated?

                       Think of it this way. If you placed a one row portal to Child|Create with no scroll bar on your layout, you could create one, but only one record simply by entering data into a field just as Set field is entering data into the _fkParentID field. In fact, you could use set field to enter data into any field in the portal's table and it would create the new record. Since we need to see the record in the other portal, we use this step to set the _fkParentID field to the needed ID value so it will appear in the original portal--that one step does two things--it creates a new record and links it to the parent record so that it will appear in your original portal.

                       The relationship will populate _fkParentIDCreate with the Parent record's ID just like it does when you use a portal to create a new record. But once you have a record in that portal, you can't create any additional records. But you could switch to a layout based on the portal's table, delete the ID from the _fkParentIDCreate field and the record will disappear from the portal--leaving the way clear to create another related record. That's why the last set field step clears the _fkParentIDCreate field, it makes it possible for the next run of this script to create another new record to appear in the portal.

                  • 6. Re: Maintain Portal Row Visibility
                    fred@kca-inc.com

                         Thanks again!  This will be great.  Once I get this new release out, I'll go back and retrofit many of my scripts to take advantage of this new (to me) technique.

                          

                         In a related issue, I just discovered that the Get (ActivePortalRowNumber) function behaves a little differently in WebDirect vs. FMPA.  When I click on a row of the Portal in either FMPA or WebDirect, I can capture the function to a global field or variable.  If I click on another button on the same layout but outside of the portal, the I can capture the function with FMPA, but WebDirect returns a 0.  Knowing this, I can work around it. 

                         Is this a known issue or should I report it?

                    • 7. Re: Maintain Portal Row Visibility
                      philmodjunk

                           There is no such report yest in Report an Issue. It would appear that this action changes the focus to the clicked button in one case and not the other as that change in focus would explain the difference in results.

                      • 8. Re: Maintain Portal Row Visibility
                        fred@kca-inc.com

                             Your previous couple of posts describe a nice way to create a new record in a child table without leaving the layout.  From what I can see, this is necessary using WebDirect for performance reasons.  It appears that several seconds are consumed each time the script changes layouts (even though the screen is "frozen").

                             My question is: Is there a comparable way to delete a child record without leaving the layout?  If I have both, I can speed up a bunch of my scripts (which are now much slower than they were in IWP).  If not, I guess I could just break the "link" to the child record then clean up on exit of the script.

                             Thanks

                             Fred

                        • 9. Re: Maintain Portal Row Visibility
                          philmodjunk

                               If the record is visible in a portal, delete portal row could delete the portal row record. But Marking a record for deletion by clearing the fk field could also be made to work. Not only could this happen on script exit, a server scheduled script could find and delete all such records once a day during a time of low database usage such as late at night.

                          • 10. Re: Maintain Portal Row Visibility
                            fred@kca-inc.com

                                 Thanks again for your help and insight. I was able to create the new child record in the same view then just set the relationship field on the child side to 0 which broke the link.  On exiting the function, I just cleaned up all of the temporary records.  It works great and reduced my code by at least 50%.  Now I have several other similar functions to apply this new technique to.