Commit Record [no dialog]
will save the record without popping up the confirmation dialog. And you can set up a button to do that step or perform a script that contains it.
But you can still get this dialog just by clicking a blank area of your layout as this also will commit your record.
One trick to prevent that (doesn't work in FileMaker GO), is to put a transparent, empty, web viewer on your layout, sized to cover the entire body of your layout. This empty web viewer object will intercept your mouse clicks to preven the confirmation dialog.
Thanks. I need everything to work on FMGo, as well. I think I found a pretty nice solution. It appears that I can use the "OnRecordCommit" (Save Button on the popup) trigger on the layout to run my script to update the user in the FMP security system. I can also use the "OnRecordRevert" (Don't Save button on the popup) to delete the record that was added. The cancel button doesn't seem to do anything except take you back to the layout so the user can't exit without committing or deleting the record. Do you see any pitfalls in this approach?
Not that I can see, but by all means test carefully as that could just mean I'm missing something key to the design of your system.
Are you asking the user to create another entry, or edit and existing entry, in the Users Table? So, when they hit 'Commit', the record they have just created is saved, and if they don't, then it is deleted?
I don't know why, but I don't like depending upon a task being completed tidily by the uninterrupted creation, modification, and then deletion of a record. It's the guarantee of the last bit that always unsettles me.
Why not change the fields on the User Create layout to be global? Then they click a button to 'Commit', and only at that point do you create a new record and transfer the data captured from the globals? No need for a deletion. And I think it might make it easier to handle the 'auto-save or not' problem.
Just a thought.
Thanks for your response.
The layout has a "+" button. The user clicks the button which adds a record to the Users table then allows the user to enter the relevant information. Once this is complete and the user clicks off the last field, the "Save/Don't Save" window pops up. When the user clicks "Save" the OnRecordCommit triggers a script to create an entry in the FMP security table. If the user clicks "Don't Save" the OnRecordRevert triggers a script to delete the record that was added. It work fine now. When I first did the "Don't Save" script, it triggered the "Save" script when the "Don't Save" script changed to a temp layout to delete the record. After I trapped this, it works great.
I like your idea of using the globals to initially capture the data then transfer the data to the new record. I hadn't thought of that approach. It may work for many of my layouts. I'll look at that for the next iteration of the application.
Thanks again for taking the time to help!
That technique also makes it easier (I find) to do all your validation checking while the data is safe in a 'sandbox', and nothing happens to your records until you are absolutely certain that the proposed data is correct.
Makes perfect sense. Wish I'd have thought of it when I started this app :) I will have to convert. I can see where it will help in many areas. It seems like it would also narrow the chance for record locks if I'm not editing the live record.
Do you typically just add a set of global fields to the same table you're working with or have a separate table with just your globals?
Some people have a separate table with only globals in it. Functionally it makes no difference - just do whatever your mind will find it easier to track. Three years down the road.
I prefer putting all globals not used in relationships in a single table. It makes for "cleaner" tables in the rest of your system and it cuts down on the number of global fields when you find that the global field you need was already created previously (which you might not discover when it's buried in another table...)
Unfortunately, I won't remember how I do it next week. I spend a lot of time commenting my code :)
I'll have to give some thought to the best way to do the globals. I can see advantages to both same and separate tables.
Is there a trick to copying a bunch of global fields to the new record without using individual Set Field script steps? How about using auto-enter in the table definition to copy the globals when a new record is created?
I surely appreciate the mind trust on this forum!
You can set up looked up value settings on the individual fields in the data table so that they copy data from the global fields when the new record is created in the data table. Your script can then be just a few lines: select the layout for the table, create the new record and (maybe) set field to set the value of a match field in the data table so that it now matches to the globals table to link them for the look up.