Portal row context not updating for different portals?

[Justin Close]

I'm having an issue with a set of portals that I have created.  We wanted a horizontal display of different related records, with tall vertical areas.  We are showing up to 3 boxes of details across a single row, so to speak.  The layout is based on "TableA".  TableA is related to "TABLEA_portals", which is just a table-occurrence of TableA (it's a self join).  The layout is based on TableA.  The portals all use TABELA_portals relationship.  These are scratch records, so we create and destroy them regularly.  The one record created at the start of the process is used to tie other related records in the set together, via the relationship.

The detail box, on the left, isn't a portal, but just fields from the local table/record the layout is based on.  It is intended that this would be the first record of all the related records, the master-record so to speak.  The next detail box is a portal to TABLEA_portals, starting at Row 2, showing only 1 row.  (See attached image; only 2 out of a possible 3 'boxes' are shown.  Each portal only shows 1 row, and each is individually defined to start at a different row.)

Part of the purpose here was to make this modular, so that more/less detail-areas could be added at will, without having to edit a bunch of script parameters or some such.  The portal row being shown would take care of all the context issues as to which record was being edited.

My problem comes along when I click a button (text label w/ button action) in one of the portals:  I want it to toggle the checkbox/field for that record in that portal row.  The label is a text label that spans over the field itself - using the field label as the button hitzone makes it a better user experience.  The button action is simply:   "Set Field [ TABLEA_portals::FieldA ; 1 (or 0)]".  The intent is to use the portal relationship to set a field for that displayed record, but the context isn't updating to reflect the portal-row that the actual button is in, like I thought it would.  (And if you hit a button on the far left, looking through that relationship should be the first record, i.e. itself, so it should also update correctly - even though it isn't a portal.)

For example, if the context is currently in box1 and I click the button in portal2, the field for portal1 gets updated, not the field in portal2.  Now, if I happen to click into an actual FIELD that is in that row, the context updates to reflect that portal row, and the buttons work as expected.  But then the buttons in the other areas only update this new context...until a field is clicked in the other detail-box...etc.  And nearly everything in these detail-boxes is a button, not a field, so the user hardly ever is actually clicking into a field.  (My screenshot shows a field that I copied to the side just so I could have one to click into.)

Anyone have any ideas on how to make this work?

Thanks,

Justin

Edited May 9, 2015 by Justin Close

[comment]

Does this work for you?

Toggle4.fp7

[Justin Close]

Before having reviewed Comment's file, here's a demo file I made up of the problem.

Now off to review Comment's file...

PortalContext_test.fmp12

[Justin Close]

Mostly, that works.  That is essentially what I have now.  The problem arises when you try to edit the record that is based on the layout directly, and not through a portal.  When those buttons fire from that non-portal context they affect whatever portal was the last active one.  One solution appears to be to put this first record into a portal itself.

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).

I just tested it in my demo file and it does work if I put RecordA in a portal also.  That is probably my solution here.  Sometimes you just have to talk it out to others to come up with the answers.    And that would make the UI construction consistent, too, instead of having one record displayed from the layout's table-context and all the others be through portals.  I suppose that it will require more row-selecting logic in some scripts, though.

I will work with it and see.

--  Justin

[comment]

 I can't figure out what your complaint is. I made that demo file because you said:
 

For example, if the context is currently in box1 and I click the button in portal2, the field for portal1 gets updated, not the field in portal2. 

​I could not reproduce this problem in my file.
 
 Now you say that the problem is:

The problem arises when you try to edit the record that is based on the layout directly, and not through a portal.  When those buttons fire from that non-portal context they affect whatever portal was the last active one.

​Well, I cannot reproduce this problem either.

 Toggle4b.fp7

Note that the action assigned to the button outside of any portal is not the same as the one assigned to the other buttons. Otherwise you would have a problem similar to the one you describe.

Edited May 9, 2015 by comment

[Justin Close]

The demo file that I posted exhibited the problem in my testing; I was, admittedly, doing a bad job of describing it originally, as I had thought that it would affect either the local record or the portal records.  But it appears to only affect the portal records:  if I click something in a portal-based record, it works fine.  If I then click on the button in the non-portal record then it will toggle the last-clicked-portal record instead.  The original file you posted exhibited the same problem.

Yes, your 4B file is immune to the issue, although the idea was to make this modular, i.e. all the same.  So the different definition on the button perhaps isn't ideal.  Putting the  first record into a portal (instead of basing it on the local layout's table) also works, and makes some sense anyway, in the 'keeping it consistent' department.

But it stills seems curious that local record's reference didn't seem to reflect that it was the first record when evaluated through the relationship for the portal.  Each of these records is related to all the other records in the set (3 total in this case).  So the first record in the set, when it is being shown in the local layout, will be related to all 3 but the effect of the relationship (if I read or write data) only results in data from the first related record.  Which should be itself in this case.  Maybe it is simply an issue of clicking a button in another context not being sufficient to actually change the context first.  But if I click a button IN a portal row, that changes context to the portal row first (which is good).  It's just a button outside a portal that doesn't change.  Or maybe there is something else going on in the engine that I am missing.

Testing in my demo file clicking outside of a portal on the layout background does change the context to the local layout record (the first record in this case), and also the related record now indicates that it is looking at this first record also (when shown in Data Viewer).  Clicking a portal row change the context to that portal's record (2nd, 3rd, etc), again in the Data Viewer.  But clicking a button outside of the portals does NOT change the context back to the 1st record.  Just seems odd.

--  Justin

[comment]

Yes, your 4B file is immune to the issue, although the idea was to make this modular, i.e. all the same. 

​Well, the current record is not the same as a related record, so that's not an option. Unless you make it related too. On that matter, it would seem that having all records in the same table, with one of them being both a parent of the entire group as well as a rank member of the group, is an unnecessary complication. I'd suggest you move to a parent-child structure.

 

Edited May 11, 2015 by comment

[Justin Close]

Yes, the parent is also a member.  I have thought about a parent-child table structure as well, and may end up there.  Fortunately, the UI I am building using portals would pretty much be exactly the same in a parent-child structure as well.