If [ IsEmpty(PortalRow) ] ??

[kennedy]

Is there a way to test if you're in the empty portal row? the portal row for adding records?

OR, is there another way to solve this problem...

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. To add a Note, you normally just click in the empty Note field at the bottom and start typing. Today's Date and your User name get entered automatically.

However, with the fields organized the way they are, I am sure some of my users will naturally try to click in the Date field and type that in. I could easily disallow entry into the Date and User field, so you had to click into the Notes field... However, to support retroactive notes and notes put in on the behalf of others, I want to support entry into those fields... on anything EXCEPT the blank row.

So, I could disallow entry to Date and User, but then put a button underneath that tests "if [ IsEmpty(PortalRow) ]" and if true, it does Go to Field "Note"; if false, it does Go to Field "Date" or "User", whichever the user clicked on.

[andygaunt]

Hi, you can script this for each of your fields.

To do this, write a script that is along the following lines (one listed is for the date field).

If ["IsEmpty(Your portal relationship::Key field)"]

Go to field ["Your portal relationship::Note"]

Else

Go to field ["Your portal relationship::Date"]

End If

OK, now, go to layout mode and click on the actual date field in your portal and in the format menu choose button and assign this script to that field.

repeat for each field in your portal that you would like to use this for (changing the field it goes to in the script)

HTH

[LiveOak]

For related notes files, I like to disable the ability to create related records and have the user enter the note information into global fields and click a new button. The creation of a new record in the related file is done with a script. To view an old note, a click on a portal row copies the notes file fields back to the globals for display or editing. Entry directly into a portal row is problematic in many situations.

-bd

[kennedy]

Why is entry into a portal row problematic?

I have several layouts that currently allow entry into Portals.

Should I not be doing that? Or not in certain case?

[LiveOak]

It is in no way a generally bad thing! For line items in which all of the information fits in the space available, it's fine. For notes, often the note is longer than the space available and the approach I mentioned can be of benefit. For any sort of process that increments through portal rows as part of a larger script, I prefer to do the operations in the related file. If you want to do some sort of list processing operation in a portal, keep your own global counters for the number of portal rows and current row. Don't depend upon the "go to next row" and "go to last row" type of constructs, do it all with the global counters. I think the problems with doing otherwise are all part of the general portal refresh problem.

-bd

[kennedy]

For notes, often the note is longer than the space available and the approach I mentioned can be of benefit.

I have my notes currently in a Portal where each row is two lines. The Note field itself is 515 pixels wide and two lines tall, so quite a bit of text fits. But if there is more there, simply clicking on the field causes the larger field to be displayed right there. Seems to work pretty nice. But...

But, it wouldn't surprise me if there are different situations that don't work nearly so well. Please advise.

P.S. Thanks, Andy, for the tip... works great... funny how obvious things can be once you have been told the answer.

P.P.S. I modified Andy's script by also checking for Browse mode vs. Find mode.