The rule is that the object has to be within the portal and in part inside the first row of the portal. However in order for any contents to show up in browse mode, you need to make sure it aligns to stay within the boundaries of the first line of the portal. So any fields with vertically middle align content are best set to top align in a portal.
The objects cannot be within the portal below the first line, but can expand from the first line and downwards. They cannot have a reach outside the portal or else they will fall outside the portal.
A good rule of thumb is to simply keep the objects fully within the first line of the portal. It can be fiddly, but you know where things are at. Using coordinates to position and arrow keys to nudge isn't a bad idea either.
You may find that you need to set the field's padding to zero in all 4 directions in order to get better results.
In the latest versions of FileMaker, the field has to be "owned" by the portal. If you move the portal, the fields should move with it without any grouping done to group the objects with the portal. If the portal moves and they don't, it's no longer part of the portal. Once the layout object is not "owned" by the portal, you have to drag it so that it's fully enclosed by the portal row before you release the mouse button. Using alignment tools too move an object into the portal row that is not already part of the portal row will leave the object floating above or below the portal and not make it part of the portal.
"... in part within the first line of the portal..." is what I've been used to, but this doesn't seem to work reliably anymore. I'd bet that if I expanded the row to include a large object, then narrowed the row so that it extends below the first row (but still within the portal) it would take... until it decided to pop out when some adjustment is made.
Concerning padding, I've never seen any object that didn't have the padding set to zero all around as default.
In part, my goal is simply to get lines of text in portal rows close together. I also used to be able to adjust the height of text fields to be very small... almost cutting into the text... so it would more easily fit in narrow portals, but now the fields have a minimum size that they won't shrink from. Is there a setting someplace that changes this?
I've never seen any object that didn't have the padding set to zero all around as default.
Then you need to check again. Perhaps you are using the "Classic" theme in an older version of FileMaker? (In version 15, "classic" no longer exists and nearly any field or button has at least some padding specified when you add one to your layout.)
The default styles for even minimalist field objects contain padding.
Yes, this database was begin in an early version of filemaker and imported, and the theme is Classic. This morning I ran into a problem caused by this (solved by searching this forum) where lines appear between portal rows even when you don't specify them, solved by copying the theme from a portal created on a non-classic layout. "Themes" are a new concept to me, and it seems I need to either specify one for my layouts, or maybe save what I've got as a theme (don't know how to do this yet...). As a classic layout, the padding is zero.
There are many advantages to be had if you become familiar with Themes and Styles and how to apply them. Assuming you are developing your solution and not just trying to address a single problem you really need to move away from Classic layouts. Classic is not a true theme but rather a legacy state to allow minimal change to layouts developed before themes were introduced. You really should not be trying to further develop such layouts, but should recreate what you need starting from a genuine theme.
Is that really different from starting with a custom theme that is basically "what I have now", and building on that (presuming this is possible?) I just want to avoid messing up the layouts I've already created by messing with it's format. I suppose the simple answer is to make copies of the layouts, change the theme, and see what happens...
By fixing my classic portal problem I realized that I can't ignore themes, and that they would make life easier even if I am only developing my own solutions right now (did paid development many years ago though, and it could happen again...)
I have had some bugs with portal speeds that use the "classic" theme on Windows clients. On Mac clients the same classic layouts are fine. On Windows there is a several second delay before scrolling is allowed. Only on some portals, not all. This is a solution that was originally made in FileMaker v 5.5.
One day I will convert the layouts out of the classic theme, for now I've added workarounds. These old layouts are so complex that recreating each one takes several hours and there are lots of them so in this case I mostly struggle on. I do know that making a new layout from scratch that isn't classic fixes it.
Is that really different from starting with a custom theme that is basically "what I have now", and building on that (presuming this is possible?)
I believe it is different. If you start with an old Classic layout and save that as a custom Theme you are starting with a whole mess of legacy workarounds intended to make the old non-theme stuff render, so your "new" custom theme uses that as its starting point. It may all appear to work OK, but under the hood it is messy to start with. If you start with an actual Theme you are building on a sounder basis. I personally think the extra effort involved almost certainly pays off in the long run.