adding portal rows without the empty portal row

[Kevin Wertz]

Okay you probably popped in here thinking this question was going to be easy...trust me I searched for an hour on here before I posted. Couldn't find an answer.

Here's the deal, I don't want to use the empty portal row. I want more control.

I had been using a scripted "new row" button that went to the child layout, created a record, came back to the original layout, and went to a designated "New Row" portal but when I do this the record is committed. I'd like to take advantage of the layout feature where it prompts to save the record or makes you click a button to commit the record. If I go to the other layout I have to save the record before I return.

I don't want to use globals because I don't want to script field validation (unique, length, etc)

And, I don't want to pop-up a window that goes to the child record layout because my solution is painstakingly IWP enabled, and opening a new window in IWP (in case you didn't know) just opens a virtual window which is full screen and you can't resize it and such. I can live with this in some cases, but not for adding portal rows.

The closest I got to what I want was using a hidden tab control with two tabs, blank and "new row". The new row button would put the user in the new row tab, go to a single row portal which used the same relationship as the view portal but with the ability to add a record, and went to the last empty portal row. At the end of the row is a save button which commits the record, and reshows the blank tab on the hidden tab control.

The problem with this approach is that I can't force the user to click the save button, as they can just click out of the record and the commit will occur. Or in IWP they will click the submit button. Of course when this occurs, my new row tab remains open and there sits the new record that was just added.

So did you get all that? I would love a new idea, or if you have an idea of how to fix my "new row" tab control idea I'd love to hear it.

[Kevin Wertz]

Okay after spending some time on this last night it looks like I'm going the route of global fields for the data entry. The real challenge will be how to make the validations dynamic. I don't mind scripting the validation but I refuse to create a separate script for each portal addition.

[Søren Dyhr]

like I'm going the route of global fields for the data entry

Or... perhaps not...

--sd

Wertz.zip

[David Jondreau]

Is this going to be used just for entry or for editing to? If just for entry, I think globals are a fine way to go. And you can validate them, even "unique" with a judicious use of PatternCount and ValueListItems.

I sometimes have a separate table just for data entry globals and name each field LAYOUT_fieldname.

If you're going to want to edit the fields at a future date, I like to use a second child TO based with a field that won't validate unless you run the script.

[Kevin Wertz]

I got most of the way with using globals but I'm stuck on how do I use globals to show related values? In other words if the user select the ID in one field I want a second un-enterable field to show the related name or description from the ID they selected.

Soren I haven't looked at the file you sent yet. Going to look now. Gotta leave here pretty soon so I may not post again until Monday. Thanks!

[David Jondreau]

Define a value list based on the field that holds the id (the real field, not the global). Set the value list to show a second field (the Name field) and only that field.

Put a second occurence of the same global ID field on the layout and set it to show a pop up menu with that new value list. And disallow entry in Browse mode.

[Kevin Wertz]

Well I'm proud of myself partially. I had thought of that but didn't think to try pop up menu. It didn't work when I tried a drop down list so I didn't even think to try the pop up menu. Thanks for the tip...works great!

Edit: bummer, I just checked and it doesn't work over IWP. I can maybe live with this though.--KW

Edited December 10, 2007 by Guest

[Kevin Wertz]

Søren,

the wertz.fp7 file doesn't include a script to add a new record, which is my main issue. I was going to allow editing within the portal. Not sure I like the wertz.fp7 approach for editing as it removes that record from the relationship. If the user escapes the screen, shuts down the app, loses connection, etc., that record is stuck out in limbo somewhere.

Edit: oh wait, I think I get it. I could use a tempID relationship to create a new record using the single new record row in the portal of this relationship, and then upon clicking a commit button I could associate it to the main record. However that still leaves the problem that the user can click out of the record without clicking the commit button, thinking they're saving the record, then there's an unrelated record in my child table just sitting out there.

I wish Filemaker had given us the ability to choose a script to run upon clicking out of the record for a commit.

Edited December 10, 2007 by Guest

[Kevin Wertz]

An update for those who may search and find this thread.

I accomplished what I wanted to do with a separate ".New" table occurrence with a tempID on the main TO to the RowID of the related TO. (thanks Soren) I used a tab control with a blank default tab and two other tabs (new row and web new row) that I named as objects. The tabs are small and I hide them behind my "new row" button, which itself is nested in a single-tab tab control (this is necessary to keep you from being able to click the hidden tabs through the new row button). Thanks to whoever posted "tab panel trick" on databasepros.com for this tip.

Upon clicking new row the system determines web or client and sends the user to the corresponding tab. Of course the fields from the ".New" TO are there and the user enters the new record (note that no portal is used). Upon clicking the save button on the row the system jumps to the table view layout of the related TO and sets the field used by the main relationship. I also included the main TO's tempID on this screen so the script blanks out the tempID here.

The user is unable to click out of the record (in the client) so this record is not committed until the user clicks the save button. I accomplished this by using a LastRecMod control field in the main TO with a validation of "LastRecMod=get(recordmodificationcount)". If the user tries to click out of the record, the custom validation message tells them to click save to save the record. Accordingly if the user tries to click "submit" in IWP it gives them a message about failed validation for the LastRecMod field and they are unable to submit without clicking my scripted save button. (I may close the status area anyway, haven't decided yet).

So the bottom line is, all this works great in IWP, the record is not committed until I want it to be, and the scripting is all dynamic. All I have to do to use this on another screen is create the ".New" TO and relationship, copy the template onto a new screen, and rename a few object names and script parameters, and place the new fields.

By the way you don't always need a "web new row" tab. The reason you might want to use a web new row tab is when you might have a related display field that shows the description of the related record. This of course doesn't work in IWP without a screen refresh, but IWP displays both fields for value lists that show 2 fields so I just eliminate the description field for the web new row tab and expand the size of the ID field.

Thanks to Soren and DJ for their posts.