Tabbing out of a portal row . . .

[Wickerman]

. . . and out of the Portal altogether!

I'm trying to set my Tab Order for a layout with a Portal on it that is used for record creation.

If the user creates a record in the portal and Tabs out of the final field, the portal creates a record on the new row and puts the cursor there, ready for action. This is great if you have to enter many rows of data, but not so good if you want to enter just one and then move onto other fields on the layout. Even if the user clicks out of the portal (which is a bit of a nuisance in its own right) -- you wind up with a useless blank record in the related Table.

So what's the best way to avoid this tabbing behavior? Should I put an "On Object Exit" script trigger on the last field in the portal that keeps the cursor to the desired field? Seems like overkill...

Also, what is the preferred method for policing the occasional superfluous, empty records that will inevitably appear in these kinds of record-generating portals from time to time?

Thanks for any pointers!

[comment]

Even if the user clicks out of the portal (which is a bit of a nuisance in its own right) -- you wind up with a useless blank record in the related Table.

Surely not - unless they have entered some data into it.

[Wickerman]

Oh! Right you are -- don't know where I got that impression.

. . . but the tabbing question is still there -- how do I set the Tab Order so that tabbing from the last field in the portal row will get you out of the portal, rather than down on a fresh portal line?

[comment]

I am having difficulty picturing the exact behavior you are after: they should be able to tab to the first empty row in order to create a new record, but not to the next empty row?

[Wickerman]

Yes - - it;s tabbing appropriately for the entry of multiple records the portal -- but I was wondering in the case where the workflow typically involves just a single record entered in a portal and then moving on to further fields on the main surface of the layout, if there was a way to tab *out* of the portal to another field rather than join to that next line.

I'm thinking now maybe I'd have to use a script trigger on that art field in the portal row -- but also thinking maybe it isn't worth the effort....

[comment]

in the case where the workflow typically involves just a single record entered in a portal

Is it entering a single additional record in the portal, or just one related record in total? In the second case, you could use a one-row portal (or no portal at all).

[Wickerman]

No -- there needs to be rows for multiple records - but I'm dealing with reveal situations where the "typical" case is for a single entry, at least at a given sitting. This is maybe not so much even a Tabbing question as a portal behavior question. For example, in another portal that has just a single field in it with a drop-down menu, when the user makes a selection, the portal automatically goes to the second row and pops up the menu for a second selection. We would prefer that after making the selection, the cursor automatically popped over to the next field, outside the portal. The current action seem very "in your face" -- see attached picture of the result after making selection.

So . . . is there a setting governing this behavior -- or should I use a Script Trigger "On Object Modify" to "Go to Field" as desired?

[comment]

You either need to use a script trigger - or disable creation of new records in the portal and move it to a scripted process.

[Wickerman]

Okay, thanks very much!

[Wickerman]

Hmmmm . . . I've written a simple 1-step script that has the cursor go to another object on the layout. If I assign this to the field with an "OnObjectModify" trigger, it works okay when I use a value from the drop-down menu in the field . . . but of course when you try to type in a free entry, the script boots you right out of the field.

I originally tried assigning the script to an "OnObjectExit" script trigger -- but this was not effective in keeping the cursor out of the next row of the portal. Nothing seemed to happen at all.

Is there a detail here I'm not getting?

[Wickerman]

I meant also to mention that when I use the "OnObjectModify" trigger, in a case where I have a multiple row portal with only field, I glimpse the drop-down menu flash open briefly before the scrip send the cursor over to the other object, which makes an unfortunate glitchy impression (on my Mac, which makes me think it will look even worse on my client' PC...)

[comment]

How about this way?

CreateOne.zip

[Wickerman]

Thanks for the demo file, but that's not quite what I'm aiming for.... in your example, what I would like to see happen is that when the cursor is in the 'Value' field, when you hit the 'Tab' key, the cursor goes immediately to the Notes field at the bottom of the layout. In your example file, the cursor goes down to the next row of the portal, which is exactly what I'm trying toy avoid.

I'm trying to allow the User to get *completely out of the portal* with a Tab keystroke executed from the last field in the portal row.

[comment]

The cursor goes immediately to the Notes field after you have created one new record. Do you want it to go the Notes field even if you have not created a new record? IOW, you will have to click inside an empty row each time you do want to create a new record?

[Wickerman]

Oh I see now . . . yes, this would be workable... But

1) Could you explain how the "not Child::ChildID" works? I'm not sure I understand what it means to have a boolean question that is simply not:field -- does that mean the field is empty? (is it the same as IsEmpty)? I don't have the Child ID in the portal line -- but I suppose that doesn't matter -- the point is the child key field is created only after the portal row is exited, hence the script is triggered - right?

2) Could you help me understand why a simple "OnObjectExit" fails to work here? I'm trying to get the hang of Script Triggers in the process . . . .

[comment]

1. The key here is that the ChildID field is set to populate on commit. Therefore, when you exit the last field of a freshly created record it's still empty. With a Number field, the expression not Field achieves the same thing as IsEmpty ( Field), considering that zero is not used.

2. What would be a simple "OnObjectExit"? You want different behavior for different circumstances.

[Wickerman]

1) Thanks for the clarification -- I've always used Text fields for my key fields. Is there an argument for using Number fields instead, or is it just a matter of habit?

2) By simple, I mean I don't understand why I can't set a Script Trigger on that final field in the portal row that triggers a Script like "Go To Field: Notes". Then in *any* situation where the user was in that field for whatever reasons, a Tab stroke would take them to that other field outside the portal. I don't get why getting into the next portal row takes precedence / neutralizes the script trigger.

Thanks for your patience!

[comment]

1. A number sorts correctly - with text you'd need to have leading zeros, and therefore also a maximum value.

2. Sure you can do that. But then you'll be tabbed from the last field of the first row out of the portal - even when a second row exists. IOW, you cannot get to all your existing data by tabbing. As a user, I'd find it weird.

TabOut.zip

[Wickerman]

Oh -- I see my error now. I didn't have the Exit Script step set to "Result:False" I'm not familiar with this obvisouly crucial feature and don't find an explanation in either of my FIlemaker manuals. . . Could I trouble you for one more explain?

[comment]

Some script triggers run the script before performing the triggering event itself; you can tell this by the note under Result in the Set Script Triggers dialog.

If you do not cancel the triggering event, it will be executed immediately after the script. In this case, the triggering event is tabbing into the next field in the tab order, i.e. the Name field in the next row of the portal. So all the script will achieve is putting the cursor in the Notes field for a split second, before it returns to its original path.

[Wickerman]

Yes, that makes sense -- but how does the "Result:False" setting in the Exit Script step achieve this cancellation of the triggering event?

"Result:False" . . . of what? What's being tested and coming up False?

[comment]

Nothing is being tested. You set the script result to be always 0 (False). See also:

http://www.filemaker.com/11help/html/func_ref2.32.68.html#1031167

[drrehak]

How about this way?

CreateOne.zip

sorry to resurrect an old post.  I would love to look at this demo file.  However, it appears to be emtpy after downloading.  could you repost? or send me another example of this technique.  thank you!

[Lee Smith]

The link works for me?