AnsweredAssumed Answered

FMPA16.01 - Portals: button doesn't fire on first click; field entered even though not enterable

Question asked by justinc on Jun 28, 2017
Latest reply on Jun 30, 2017 by justinc

I have noticed a couple of issues with portals recently, when using FMPA16.01.

1)  Portal button doesn't fire:

     I have a button in each row; it's not ever hidden.

     This button does not fire until you click into the portal row once and then click the button.  (You could click the button twice - same effect as clicking into the row first, and then clicking the button.)

     Clicking into another row the first causes the highlight on whatever row was active to disappear, so something at least is happening when the first click executes - it's just that the new row doesn't get highlighted, and the button doesn't fire.


2) In conjunction with the above button issue, the clicked on portal row doesn't become 'active'

     I have an active row state set such that the background turns blue when that portal row is active.  But when first clicking into a row, the row does not become active (i.e. I don't see the highlight).  But the second click does make it active.


3) I have a script on these buttons that do a commit, but then go back to the first row in the portal.  When it does that, there's a field that becomes active and in focus, with the cursor in the field.  This field is configured to be NOT 'Enterable in browse' mode, however.  (This problem happens in 15 as well.)  I have removed all objects on the layout from the tab order - why does this field become editable and infocus?  (I have verified that changes can be made in this case.)


Items 1, 2, 3 all show up in both FMPA 16.01 and 15.03. I type this, I recall issues with portal buttons not firing in 15 if the current focus was on a button that was hidden in the target row - not that the target button itself was hidden...or was it the field that was hidden?  Anyway, this seems like it could be similar when considering Item #3: the field is non-enterable in the target row so the first click on a button in the target row causes the engine to get confused and stop: it tries to enter the field in the new row, but it can't and so it stops processing all other actions.

     I did some testing and this appear to be the case:  If I am in Row 1 with the non-enterable field in-focus and editable (when it shouldn't be - Item #1), my next click on the button in Row 2 (for example) fails - and the row does not become 'active' (item #2).  But it DOES cause the Row 1 field to become non-active/in-focus and for Row 1 to lose 'active row' status (as indicated by the row highlighting at least - but "get(activeportalrowNumber)" still reports Row 1 is active, even though it's not highlighted).  And if you click on the button in whatever the current row is, it will fire just fine, it's just when it transitions to another row, and the non-enterable field is in focus, that it craps out.


Oh cool - I was able to recreate all of this in a new file - I was afraid it would work OK there.  It usually does when I come across these things.    I was able to recreate this problem in files created in either 15.03 or 16.01.


I have attached the example file from 16.  It should auto-login with Admin (full access).  This file demonstrates all three issues noted above.  It was created from scratch in 16.01 and just uses whatever default Theme it...well...defaults to.  To recreate:

     1) Open the File

     2) Click on one of the 'click me' buttons - this should return you to row one and the "Name" field (configured to be non-enterable) will become in focus and editable.

     3) Click on the button in row 2 or row 3 - the new row doesn't change and the button doesn't fire; the old row loses the 'active' condition.