I just tested this process in FM13 and had no problem achieving the result you desire. Of course you must make sure the button (or whatever object you want to make into a button) fits entirely inside a portal row. I tested it as follows:
1. Drew a rectangle over the fields in a portal (just to test if it bahaved differently from starting with the button tool), defined it as a button, then moved the rectangle behind the fields using Send Backward as many times as needed.
2. Drew a button, defined it then moved it behind the fields using Send to Back.
In both cases it only goes to the back of the objects within the portal and functions properly.
3. Moved the button down until it was just into the next portal row, then sent it to the back.
4. Moved the button up until it was just outside the portal itself, then sent it to the back.
In both cases, although the button still APPEARS to be over the portal object it is in fact behind it and no longer functions as a button.
One final comment: I am certain this is no different to FM12 and earlier.
I've created a smail file to illustrate the difficulty I'm having. Maybe you can see right away what I'm doing wrong. I placed a rectangle object, formatted as a button, directly above the field editbox in the portal row. According to the Inspector it is exactly the same size as the editbox and in exactly the same location. First of all I would have expected the rectangle to appear in every portal row. Secondly, when I go into layout mode and send the rectangle/button backward, It falls below the portal and can't be clicked upon.
PortalTest.fmp12.zip 66.5 K
Here is your file fixed so it works. In your file, even though the button appeared to be inside the portal row it was in fact outside of the portal, just sort of hovering over it. Thus it completely covered row one where it appeared to work, but didn't work on the other portal rows. Actually it only appeared to work but didn't really since it was not being activated from within the portal and was thus going to ALL related records, not a specific portal row.
What did I do?
1. Cut and pasted your button so that it was actually within the first portal row
2. Made the name field in the portal transparent so you can see the button (this is not essential, just to help you see what's going on)
3. Added a button to the child layout to return to the parent layout
PortalTestFixed.fmp12.zip 66.3 K
1 of 1 people found this helpful
I have encountered the same issue. It seems to be a CSS based problem to me.
In pre fm12, a portal row of 22 px, and a row button object (no border) of 20 px, positioned 1 px below the portal top position, worked nicely.
In fm12, often out the window.
It seems to me it is possibly due to the way the CSS calculates sizing, if you have done any html/css then think in terms of the margins, padding and border calcuations, some parameters add to the total width/height, some don't.
Sometimes resizing and repositioning works, sometimes not; when not duplicating the object often works - older object with engraved/embossed can complicate things further.
In short, conversion to fm12 causes the row button object to effectively sit on the portal border, and is interpreted as being 'outside' the portal.
Pixel perfect rules again, after allowing for conversion object changes.
Just my observations.
So much as keywords has effected.
On your original file, shrink the vertical height of the row button (16px) and move it 1 pt down, the button then appears on each row.
So this suggests it is a sizing issue, and overlap/superposition as the culprit
The portal row height is 27 pt, if the row button is also made 27pt, and reposition at the top margin of the portal (i.e. move it back up 1 pt), a button occurs on each row. So how is that?; meaning so much for the superposition idea. Some sort of retriggering of size calcualtions?
The stacking complication ( think z index) I get too, the *&*%^ button will just not drop down behind the fields; again it is a position/size/ based fix
In the quirk basket.
1 of 1 people found this helpful
All the resizing unnecessarily complicates the issue. It is simply a case of the button being over but not in the portal. Try the following:
1. Select the button and Send to Back—button disappears, but is now actually behind the portal itself. Button now does not work at all (not surprising).
2. Select the button and nudge it 4 or 5 px to the left (so that its left edge is to the left of the portal edge), then back again, then Send to Back—button now goes only to the back of the portal contents (ie. behind the field) and now functions correctly.
Why does this happen? Who knows, but it is simply a matter of making sure it is entirely contained within the portal row itself.
<<All the resizing unnecessarily complicates the issue>>
not if one wnat to understand why it occurs.
<<Why does this happen? Who knows, but it is simply a matter of making sure it is entirely contained within the portal row itself.>>
being 'contained' would be a sizing and positioning issue, would it not?
Its intended behavior. Both Portals and Tab panels have this special effect capability.
Both objects have layers. An object pasted onto one of these objects has the option of ‘floating’ above the Portal or Tab panel. To actually put the object into the Portal or Tab Panel you can move the object with the arrow keys or do something else (like align right) that indicates to FMP that the objects are to be on the same layer instead of separate ones.
The purpose of this is to allow the developer to overlay objects in front of the Portal or Tab Panel. For example a message field that needs to display on all Tab Panels. The text “Test Order.”, formatted in light grey, might be used to tell the user that the current order isn’t valid.
Well, I wish I knew more about how be sure that an object is "contained" in a portal or tab object but maybe I'll find more about that in the documentation now that I have an idea what I should look for. For now it's enough to know that I can still place a button below fields in a portal row and to just keep tweaking its position until FileMaker realizes that it should be contained within the portal.
Thanks everybody for your help.
This has been a frequent frustration of mine as well. I have a printed layout that has a couple of portals that are pretty small (let's cram as much info as we can!), so the portal rows are barely large enough for the fields, actually smaller in some cases. The fields sit "inside" the portal, but sometimes when repositioning them, they "pop out" of the portal, and sit on top… therefore it only looks like they are in the first row and not the others - of course they are not in any row, but that's how it looks.
It's confusing to tell which moves are going to work and which ones will cause an object to come out of the portal. It would be nice if there were a way to have objects in portals more "sticky" within the portal… like you would really have to deliberately TRY to get them out of the portal. Or have a menu command and keyboard shortcut required to get an object out of it's confines of portals and tab objects. And/or have some attribute in the Inspector that would indicate that the object is "contained" in another object.
Moving an object can easily move it out of the bounds of the portal, making it no longer part of the portal layer.
You can test for this. If you move a portal the objects inside (stuck to) the portal will move with it. So the if your fields don’t move with the portal when its moved then they have become unstuck.