3 Replies Latest reply on Nov 11, 2013 12:55 PM by philmodjunk

    Help with Portal Script (rows)

    BillieMead

      Title

      Help with Portal Script (rows)

      Post

           Hi all,

           I have a table for tracking time [timedata_tracking] which is in essence a timesheet with activity codes and am using a related table [breaktime_data] to track timestamped breaks (in and out timestamps). I placed [breaktime_data] in a portal (Allowing records to be created) and am using two scripted buttons for clocking out and in of breaks. The Clock Out script (Img attached) checks first to see if user entered a break_type ("Break" or "Lunch", each with different time allowances). But I am stumbling because of the fact the Filemaker always has an extra row shown in the portal so even if the last row has data input, the script loops to a new row and finds the field is empty.

           Thanks for any suggestions, I'm sure the answer it's a simple solution.

           Billie

      StartBreakSS.jpg

        • 1. Re: Help with Portal Script (rows)
          philmodjunk

               FileMaker will only have that "extra row" if "allow creation of records via this relationship" is enabled for the portal's table occurrence in the relationship on which the portal is based. Clear that check box and the extra row disappears. But this will also eliminate the ability to add new records in the portal simply by entering data in that "extra row" so you'll have to decide if that is a desirable change or not.

               How is the script shown performed? By clicking a button inside the portal or outside? If this is performed by clicking a button outside of the portal, there's no code to select a specific row of your portal and thus the script will access the first portal row. If this is performed by clicking a button inside the portal row, there's no need for the go to object or go to field steps and references to fields in breaktime_data--assuming that is the portal's table occurrence name, will refer to the row where you clicked the button.

               I also suggest not using scripts steps that start with "insert" to modify fields unless you have no alternative method of doing so. In this case, set field can be used instead.

               Also keep in mind that many scripts that interact with related records shown in a portal do so by using freezing the window, then pulling up this same set of records on a table based on the portal's table, making whatever changes are needed and then returns to the original layout.

          • 2. Re: Help with Portal Script (rows)
            BillieMead

                 Thanks... great explanation.

                 I can add Create New Record in the script so I will try that now and disable "allow creation of records via this relationship".

                 The button is outside the portal and I included the Go To Object because of multiple Portals on the layout. I hope that was correct.

                 If it's not to much to ask, why your suggestion to use SetField instead of insert? Just so I can learn.

                 And I believe your final point is that Go To Related Records would be much of the same as using a portal in Filemaker?

                  

            • 3. Re: Help with Portal Script (rows)
              philmodjunk
                   

                        The button is outside the portal and I included the Go To Object because of multiple Portals on the layout. I hope that was correct.

                   It's correct but possibly incomplete as I noted earlier. Since you could have many different records in your portal, there's nothing in your code to put the focus on a specific row in your portal. Unless the desired portal record is always the first record--and the right portal sort can make this the case, the script cannot always access the correct portal record.

                   Script steps that start with Insert as well as the copy and paste scripts steps all require that the referenced field be physically present on the current layout and behavior settings in the inspector must be set to permit browse mode access. If this is not the case, nothing happens and no error message appears. The only way that you know that the step failed is if you add code to check for an  error code or notice that the script did not produce the desired effect on your database.

                   Thus, a future minor modification of your layout could "break" your script when such a step is used in your script. Set field is not limited to fields present and accessible on the current layout so it is a few percentage points less "fragile" than an insert step.

                   I usually reserve the user of such steps for working with container fields and for "edit" scripts that modify the contents of a field at the specific location marked by the edit cursor.