8 Replies Latest reply on May 9, 2015 12:18 PM by disabled_JustinClose

    Going to Portal doesn't automatically make a row active?


      Going to Portal doesn't automatically make a row active?


      I have a couple of portals on a layout that look through the same relationship, but show different records.  I.e. portal 1 shows is set to start at row1, portal 2 starts at row2, etc.  Each portal has a unique name.  What I have found is that if I script the process of going to portal2 for the purpose of reading/writing/deleting/etc information about that 2nd record, it doesn't automatically make the portal row/record active.  My script gets an error 3 ("wrong mode") when trying to set a field on that row for instance.

      What I have done in my scripts is add an 'go to portal row [first]' after going to the portal object.  This seems to work, but just caught me off guard.  I guess I haven't tried naming an object within the portal row, just the entire portal object.

      Is this normal portal behavior?  I thought giving it a name and going to that object would activate the row itself (and thus put my script in the context of that related record).


      --  Justin

        • 1. Re: Going to Portal doesn't automatically make a row active?

          It's normal to use Go to Portal Row to highlight a row.

          • 2. Re: Going to Portal doesn't automatically make a row active?

            Well, I guess that's good to know.

            Here's a twist on this problem, though:  in these same portals it doesn't appear that the context changes when clicking a button on that portal row.  I have 3 of these 1-row portals, each showing a different starting row.  If a click a button in portal2 that does a simple set field via the same portal relationship (with the intention that it would be updating the field shown in that portal), it might actually set the field in portal1, because that is where the context was.  Here's what the set field defined for the button action might look like:   set field [tableA_Portal::Field1 ; "1" ]

            I am trying to make this a modular setup, so more portals can be added, and I don't have to go in and set up each button with a script and then a parameter.

            Any suggestions for that?

            --  Justin

            • 3. Re: Going to Portal doesn't automatically make a row active?

              Can you share your script and how each of these one row portals differ from each other?

              Using a mouse click on a button in the portal row is a pretty standard way to put the focus on that portal row. I was just working with a portal based picklist that relies on that very behavior in order to work.

              To post a script to the forum:

              1. You can upload a screen shot of your script by using the Upload an Image controls located just below Post a New Answer.
              3. You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here. (with this approach, you can get multiple script steps on the same line, please edit the pasted text by inserting some returns to separate those steps.)
              5. If You have FileMaker Advanced, you can generate a database design report and copy the script as text from there.
              7. If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format.
              • 4. Re: Going to Portal doesn't automatically make a row active?

                There isn't a script (at the moment).  I was trying to avoid making one.  The only action is a single step button:  "Set Field [ TableA_Portal::Field1 ; {1 or 0} ]"

                I will see about making a mockup file I can post.

                • 5. Re: Going to Portal doesn't automatically make a row active?

                  OK, here's a demo file (https://dl.dropboxusercontent.com/u/15429649/PortalContext_test.fmp12).  (Can only attach images, huh?  Oh well, this link should work.)  It exhibits the problem I was talking about, but, it also demonstrates that it sometimes works.  :)

                  If you are going from detail-box2 to detail-box3 and clicking the buttons, they work great.  It is only when you click a button on the detail-area1 (which is not itself a portal, since it is just based on the layout's table), then it will toggle whichever portal you last were clicking in.

                  So maybe the answer is to just make detail-area1 into a portal as well...

                  --  Justin

                  • 6. Re: Going to Portal doesn't automatically make a row active?

                    Looks like putting the 1st record's detail in a portal fixes the issue; and it will make the layout's construction more consistent.

                    But the logic still seems to me that it should work:  if I am on Record A in a layout based on TableA, which is related to 3 records in a TO of TableA through RelA (a self join), and the first record in those related 3 is RecordA itself, if I change a field through that relationship it should still be changing RecordA (because it is the top/first of the related records).

                    --  Justin

                    • 7. Re: Going to Portal doesn't automatically make a row active?

                      "Set Field [ TableA_Portal::Field1 ; {1 or 0} ]" is shorthand for a different expression for those reading this thread.

                      Your download link is missing the ?dl=0 parameter

                      I was able to tack that on to the URL and download the file.

                      I assume that the buttons in questions were the ones overlying the "A, B and C" check box fields. Using Windows 7 and FileMaker 13.0v5, they appear to work perfectly. Clicking the button sets the underlying field of that portal row to the "not" of it's value and the one row portal row highlights.

                      I don't quite see the purpose of the buttons, however as I can get nearly the same results by removing the buttons and clicking the check box fields directly. The only difference: clearing the check box leaves a null value in the field instead of zero, but this can be managed by either an auto-enter calculation on the field or it may not be an issue as null values in FileMaker usually evaluate as zero.  ( If ( IsEmpty ( self ) ; 0 ) would work as an auto-enter expression.)

                      • 8. Re: Going to Portal doesn't automatically make a row active?

                        Well their description is confudling; I used the 'Copy Public link...' link before.  It says, 'To share this file with others...'. 

                        But if you go to the website and pick 'Share', then it gives you this link (as you were noting, with the '?dl=0' parameter):   https://www.dropbox.com/s/3mvwxasf6j8p0rs/PortalContext_test.fmp12.zip?dl=0

                        Oh well, this link here is now also a zipped up version, which should download regardless of whether or not the parameter is on the URL.  At least it did for me.

                        Yes, that calc was a bit shortened version of this: Set Field [ TableA_Portal::Field1 ; not ( TableA_Portal::Field1) ]


                        (Silly forum page isn't respecting the formatting that the editor let's me apply, unfortunately.)

                        Yes, it was specific to the buttons over the A, B, C fields.  The problem arose when clicking between the portal records and the local/non-portal record.  If you click a button on a portal, then go click a button on the non-portal row, it changes the data in the portal record.

                        The purpose of the buttons is purely user experience, not really anything related to functionality.  The user can now click anywhere amongst the label or the box and it will toggle the value.