Validating Field Data in Portal Row

[Wickerman]

Simple situation not behaving as expected.

I have a Layout with a Portal to a child table. The Portal is displaying 5 rows and there are 3 Fields displayed on each row. Record creation is allowed so that the User creates Child records by simply entering data on the freaks line. No problemo.

So, the final field in the Row is set to require Validation: "Not Empty". So if I enter data in the portal and then click outside the portal, sure enough, the Validation message pops up as I set it, to ask for a value in that Field.

But I find that if the User simply Tabs out of that last field into a new portal row, he can work merrily along on this new record while the previous one remains incomplete, and so on. This surprises me because I thought a portal row would be "committed" as soon as you left a row, and trigger the validation Alert.

I don't want the user to make 3 portal row entries and then get blitzed with three of these validation Alerts one after the other.

So --

1) first a conceptual question - am I learning that any data entered in multiple portal lines is left uncommitted until the portal is exited?

2) What's the fix here -- a Script Trigger set "On Object Exit" . . . where? Is there a way to trigger a script when a Portal *row* (as opposed to a portal field or the portal itself) is exited? Should the script simply "Commit Record"?

[imoree]

But I find that if the User simply Tabs out of that last field into a new portal row, he can work merrily along on this new record while the previous one remains incomplete, and so on. This surprises me because I thought a portal row would be "committed" as soon as you left a row, and trigger the validation Alert.

Unless you lets say define a $isValid variable that requires the following:

$isValid =

not isempty( Field::One) and

not isemtpy(Field::Two) and

not isempty (Field::Three)

Once that is complete , then you can call your script to do what it has to do. However you need to have ALL fields together to

Certify they are entering in COMPLETE data.

Understand?

[Fitch]

1) first a conceptual question - am I learning that any data entered in multiple portal lines is left uncommitted until the portal is exited?

2) What's the fix here -- a Script Trigger set "On Object Exit" . . . where? Is there a way to trigger a script when a Portal *row* (as opposed to a portal field or the portal itself) is exited? Should the script simply "Commit Record"?

1. Yes, and that is a feature!

2. Yes: a script trigger on object validate (requires FM11) would probably be best -- that way if a user tabs through existing portal rows, it will only trigger if the data in the field has changed.

[Wickerman]

Thanks for the replies but I'm still not quite hearing the solution. I am in FM11.

I have three fields on the row. Only one (the last of the three) *requires* a value. To which object am I attaching the script trigger? The Required Field only? (What if they never visit it?) All fields in the row? (Won't that cause the Validation alert to trigger when tabbing out of the first field, before the user even gets to the required field?) The Portal itself? (But that means the user can enter 3 rows without the required field and then get hammered when they exit).

"On Object Validate" seems to miss the problem -- aren't I *trying* to get the record to Validate so the Field Requirement will be triggered?

Sorry if I'm being obtuse here . . .

[bcooney]

imho, I wouldn't allow creation. I would design a popup window to add a record, and throw all the validation into the OK button on the popup (the other choice would be Cancel).

Yes, portal records are not committed until the parent record is committed (the basis of transactional techniques, btw).

Perhaps a script trigger on each field in the portal that commits -- and therefore throws the validation dialog? I'm not fond of the dialogs, and while I do feel that is the best method to assure that you will not commit a record without a value in that field, I would do the popup for a better interface.

[Wickerman]

Really? I've taken that approach before, but I've found the user experience feels markedly tedious when there are all of these pop-up windows or pre-entry global fields and "Enter' buttons involved -- especially in cases where I might, as here, have 2 or 3 of these portals on a layout. It starts to feel more attractive to make a nice big free-text box and tell people to put a carriage return between entries?

The problem with a script trigger on each field is say I have three fields in this order: Date, Note, Initials. And say "Initials" is the required field. So the user Enters a date, but when she tabs to the Note, a dialogue box flies up and say "Initials are required." before she even gets that far -- Wouldn't it?

[bcooney]

All these popup windows are pre-entry global fields? Why? A simple popup, new record in child table. Cancel would delete the new record.

[Fitch]

Allowing creation of related records via portal has always come with tradeoffs. E.g., a delete button that appears on the empty row.

In this case, I think the attached file might work for you. The script trigger is attached to the portal itself, on object exit.

portalTrigger.zip

[Wickerman]

Thanks Fitch -- looks like that does the job. It's a little non-intuitive for me because I didn't think that tabbing from one portal row to the next constituted "Exiting" the portal -- I would have thought when you exited the portal, the new record in the portal would be committed, but maybe that's what you meant by this being a "feature"?

bcooney -- maybe I'm not picturing the right sort of thing by "pop up" -- I'm at least envisioning that the User would click a button to get the record-entry window to "pop up" and a button on that new window that the user would click to enter the data and close the window -- and if there were say three records to enter, they'd do all that three times? To avoid that, I'd do an alternative set-up with some global data-entry fields on the layout and an "Enter" button to load the data into a record --- but that takes up a lot of real estate on the layout, it seems. . . .

[adyf]

Allowing creation of related records via portal has always come with tradeoffs. E.g., a delete button that appears on the empty row.

In this case, I think the attached file might work for you. The script trigger is attached to the portal itself, on object exit.

Fitch, on the attached demo is the conditional formatting set right for the red X label? It is still visible on the ghost portal row unless it's meant to be.

[Lee Smith]

The conditional Formatting calculation is commented out. I believe it was because of the field used was based on the related table. I remove the "/*" $ "*/" which then let me know that the problem was with the field.

HTH

Lee

portalTrigger.fp7.zip

[mr_vodka]

Change the conditional format to be

IsEmpty( child::id )

[adyf]

The conditional Formatting calculation is commented out. I believe it was because of the field used was based on the related table. I remove the "/*" $ "*/" which then let me know that the problem was with the field.

HTH

Lee

Change the conditional format to be

IsEmpty( child::id )

Thanks guys I understand now.

Could you tell me what the below expression means please:

"/*" $ "*/"

[Lee Smith]

It means that I made a typo

The $ was suppose to be & ( i.e and).

[Fitch]

Sorry for the confusion. The file was intended to demonstrate the script trigger, so I was focused on that, and not paying attention to the conditional formatting of the "x" button, which as you can guess was copied from another file. Thanks for providing the correction, John.

[Lee Smith]

:getlost:

[Fitch]

Lee, it wasn't clear to me from your first post that you had made the correction in the file you posted. I downloaded it and see that you did. Good catch, and thank you!

[Lee Smith]

Hi Tom,

Good point. I should have commented about that, or added 2 or mod to the file name.

Lee

[Timothy Ackerman]

Fitch, this little solution just made my day.  Woke up at 5am in a sweat that my validation script wasn't working for any rows after the first portal.  

Thank you!