1) This is difficult to do as you asked. But there is a fairly easy way to accomplish much the same functionality. Which is, don't have a blank row. Put a "New" button above (outside) the portal instead, to create a new record/row.
The relationship would be sorted, descending, on a Timestamp field, which used the option to auto-enter [x] Creation Timestamp. That puts the most recent at the top. The new record created by the button is the latest, so it would be on top;
Go to Field [ portal relationship::field ] would hit it, as the default is the 1st row.
The relationship no longer needs [x] Allow creation of related records.
2) The question is kind of ambiguous. What exactly are you trying to get? If it's an "expanding portal", you can get this by setting the object anchor of the portal to the bottom, so it gets more rows if you resize the window taller. But only if you manually do that.
Otherwise you may want to consider using Go To Related Record [ portal relationship; a layout of the portal's table ]
3). I would put a button to delete on each row. Otherwise it is too vague as to which record/row; and it really matters.
As far as the "extra" button you get in a blank portal row: 1. There would be none if [ ] Allow creation is off. 2. You can create a calculation field for the button, if [x] Allow creation is on, in the portal's table, with a result of Container. More complex, but worth it. No one likes the darn button in a blank row; tho it does nothing.
P.S. I just put a little gray trash can, set to Delete Portal Row; it takes up little space, is intiutive and safe. I NEVER check the option, in the portal dialog, to [x] Allow deletion. It is not needed if you have a button. If it is on, a user can try and delete the row without a button. But if they lose focus, are actually outside the portal, and do not pay attention to the dialog, they can delete the main record by mistake.
1) Thanks, this does satisfy me pretty much. Just one small thing that would be a bonus: when I hit the "New" button, the new row always appears on the bottom. Is there a way to make the new row appear on the top? The reason is because, if I do sort by timestamp descending, the oldest record is on the bottom. When I hit the "New" button, the new row appears below the oldest one, which time-wise doesn't make sense, even though, yes, when I commit the row, it reappears at the top of the list
Also, right now, my "New" button is a script:
Go to Portal Row [Select; Last]
Go to Field [appointments::notes]
There's a conflict on this when I don't have a vertical scroll bar and my number of records is equal to or exceeds the number of portal rows. Is there a better way to do this? I tried "New Record" but that only makes a new record of the current layout's table, not the portal's table.
2) What I want for this is a portal that shows all related records. Essentially, the "Go to Related Record" thing does the same as what I want except I seemed to have a problem. Say I'm viewing a patient's information, and he hasn't had any appointments yet. When I hit the "Go to Related Records" button (that goes to this patient's appointments) it doesn't work because he doesn't have any. It's supposed to go to an "appointments view" layout that shows all of the patient's appointments. Is there a way to overcome this?
3) You're right about the vagueness. I'll do the trashcan icon. Thanks for the idea!
1) The problem is that you need to Commit Record, for FileMaker to evaluate the descending Sort including that new record. I do not use the "portal row" commands myself for such things. I go to the real child table. This is psuedo code of how I do it:
Enter Browse Mode
Set Variable [ $id; primary id of main table, Patient in this case ]
Go To Layout [ layout of child table, Appts. in this case ]
Set Field [ Patient ID (foreign key); $id ]
Commit Record [ no dialog ] <-- important
Go to Layout [ original ]
Go to Field [ portal relationship::field, Appointments::Notes in this case ]
The Commit lets FileMaker register that new record and its auto-enter entered Timestamp field, so it will sort to the top of the portal by the time you return to the original layout. It seems like extra work, but not much.
2. This kind of does not make sense (to me). You first say there are no Appts., then you say you want to "show all Patient's appts". It would be possible to bypass the portal during the Create Appt. script, ie., just stay on an Appt. Form layout. That would be appropriate if there were lots and lots of fields to fill out in the Appt. But otherwise I don't know what you mean.
3. The trashcan is just a little icon, which has been embedded in a container field (with global storage if in that table). But there are various ways to do this, the best being using a Constants (or Globals) table, with a single record (enforced via Privileges), where you can put it in a regular field (not global).
In any case, you then need a calculation field in the table where it appears, Appts. in this case.
Case ( not IsEmpty (Patient ID); Trash can field )
The field you test against can be any field that you are sure has data. The reason for this is that the blank row of a portal does not have data, hence will not show a calculation based on data. It will show a plain global field on a blank row; because a global field does not belong to any particular record, hence does not care whether it has data.
The blank row is a bit of an anomaly. Is it a record? Well, no. Does it belong to the targeted table? Well, yes. So, does it exist? Apparently, but as what?
But you don't need this for the Appts. portal, as there does not need to be a blank row. Turn off [x] Allow creation of related records in the portal's relationship. Use the New Appt. button instead.
Thanks again for your details answers, Fenton Jones.
Just two more questions! :)
1) When I'm in List View, how do I sort by timestamp (field) descending by default? I can right-click and go to Sort to do it, but when I leave the layout and go back to it (via a Go To Related Records button), its sort is reset to whatever it was before.
2) Is there a way to make a button that says "If I'm in Browse mode, clicking this button will go to Find mode. If I'm in Find mode, clicking this button will cancel the find and go back to Browse mode."? I tried doing a script, saw the "If" command but not sure how to proceed from there.
1) If you're talking about the Appts. table, the relationship can be sorted by Timestamp descending. It is one of the options in the relationship box. You may just be sorting the portal itself, but sorting the relationship will cause the targeted records to also be sorted when you Go To Related Record.
2) This is accessible via the function, Get (WindowMode), 0 for Browse, 1 for Find, 2 for Preview.
If [ Get (WindowMode) = 0 ]
Enter Find Mode 
Enter Browse Mode 
The trouble is, people might expect it to actually DO the Find when they click on it, when they are in Find mode, rather than just switching back to Browse Mode. That's a bit more work. I usually just leave it as is, and make them learn more about using FileMaker Finds. They just have to hit the Enter key to do the Find.
Thank you, you've been of utmost help! :)