When the natural place to add a row is on top?

[kennedy]

Most my files support "notes"... a portal that has three fields in each row... Date the note was entered, User that entered the note, and the Note itself. The Notes are sorted by Date, descending... so the most recent note is first, and the oldest note is last.

Thus, when you add a note, it will naturally be inserted at the top of the Portal. But the blank row you click in is at the bottom of the Portal. The user will find it non-intuititve to go to the bottom to type in a record that belongs at the top. They will also find it upsetting to have the bottom row jump to the top when they hit "enter".

QUESTION 1: Is there anyway to get the empty row to appear at the top of the Portal?

If no, then the next best solution might be a "Add Note" button above the Portal. I could implement that by jumping into the bottom blank row... however, that may still be surprising to them, and still suffers the jumping upon entry of the row. Alternatively, I could have Add Note create a blank note with Date and User, refresh the Portal resulting in that blank note getting sorted to the top, and then do go to into the Note field of the newly created first row.

Two issues with that. One is that if you leave it blank, the row doesn't go away... you just have a blank row. I can live with that. Second issue, give a user can modify the Date of a note to some Date in the future... the newly added row may rarely not be first. Given that, ...

QUESTION 2: How do I create a new portal record, refresh/sort the portal so that the new record appears where it belongs, and then (the hard part) how do I go to a field in that newly created record??

Thanks!

[Vaughan]

Yes. Always have an "empty" record in the related database, and sort the protal so that the "empty" record appears on to while the rest of the records appear sorted appropriately.

Some cool scripting will be needed to ensure a blank portal record is always created after a new record is added.

Note that a blank could create slight problems with summary reports in the reelated file, but this is easily solved by ensuring that it is omitted before the reports are generated.

Both of these techniques will require a very firm hand on the user interface to be robust and reliable.

Alternatively, create what appears to be a "blank row" on the layout just above the real portal. (Yeah, I like that idea... I might use it myself. Thanks!)

[kennedy]

Alternatively, create what appears to be a "blank row" on the layout just above the real portal. (Yeah, I like that idea... I might use it myself. Thanks!)

I like that idea, too! (I like to keep layout stuff out of the data... and vice-versa.)

The trick will be making [Enter] behave properly. If the fields in the blank row are implemented with globals, then pressing [Enter] needs to create the related record. Any thoughts on how to do that?

Here's another idea: put two of the same portal on top of each other... but set up the first one such that it doesn't match anything. Hmmm... not sure how I do that.

Any further direction would be appreciated... I haven't really exercised Portal functionality that much... just standard stuff so far.

[andygaunt]

The trick will be making [Enter] behave properly. If the fields in the blank row are implemented with globals, then pressing [Enter] needs to create the related record. Any thoughts on how to do that?

Well, the simplest answer would be to make the "blank row" have a script attached to it, that pauses and waits for enter to be pressed. Then it generates the related record and clears out the data ready for the next portal item.

[kennedy]

Or instead of enter, it could wait until none of the fields in the blank row are the current field, right...

Loop

Pause [ 1s ]

Exit Loop If [ not (Status(CurrentField) = "Field1" or Status(CurrentField) = "Field2") ]

End Loop

Would that work?