Hi All, This will sound like a rant, but before I begin I would like to say that I would *love* to be shown my ignorance and corrected that the "Unrealized Feature" I write about is indeed "improperly implemented" on my part.
So this whole thing where you can set a layout not to Commit Automatically -- wha-hoo! This was supposed to free me from the FM6 (and prior) Kludge that many of us used to use: FM6 Kludge: So I want to have the end user enter First, Last and Zip for new Clients. But I don't trust end users to use "New Record" since the data integrity was atrocious. So I create the global fields gFirst, gLast and gZip. I place them all on a layout. For the "New Client" button I clear them all and go to that layout, when the end user clicks "Post" it validates that the fields are all non-empty and that the Zip Code has a related record in my Zip Codes table -> if the validation passes, a new record is created and the First, Last and Zip fields are set with the values in gFirst, gLast and gZip respectively and the City and State fields are setaccording to gZip and the script returns to the previous layout -> else a validation failure message is displayed and the script halts. Alternately, if the end user clicks "Canx" then the three global fields are cleared and the script returns to the previous layout. (And for the "Edit Client" button the process is essentially the same only the globals are filled with the current record's values and post does not create a new record.) (Essentially using a bunch of globals to create a pseudo object and using ORM techniques). FM9 -- The Promise! The promise of the ability to set a layout to NOT automatically commit was that this Kludge would be unnecessary. Until the end user clicked "Post" the changes were not made, and the new window could either be a current record or a new record -- and the New Record didn't "take" unless it was committed (but the serial id was incremented annoyingly -- but I quibble). FM9 -- The Reality... Although you can attach logic to a Post and a Canx button that would do what you wanted with the FM6 Kludge, if the end user happens to click outside of a field she/he will be prompted whether or not to Save Changes to the record -- An Esoteric prompt that completely obliterates the attempt to make Adding Records immune from unsophisticated end user mischief. And! If the end user (as one would normally do) clicks "Save" and then upon clicking "Canx" the record exists and none of the scripted validation was applied. FM9 -- I hope I am wrong... Please, I hope that someone can correct me. I hope there is a strategy the emulates the FM6 Kludge that I am failing to see. Otherwise, I am going to revert to the Kludge to get my robust Date Entry/Edit with robust Validation strategy implemented. FM10 -- How about a true Object? (or a "Holder Record" if FM wants to protect the end user from scary IT words) You can set a layout to be a "holder" layout, where without "CommitHolderRecord" everything about the record (the empty values for new or the edited values for existing) are lost. You could have "GetHolderRecord[new]" and "GetHolderRecord[current]" to work with "CommitHolderRecord[new]" and "CommitHolderRecord[current]" (respectively, except that Get[current] could work with Commit[new] for a Duplicate routine). All scripts run for fields for a Holder Layout apply to the Holder Record only, and only upon Commit are all auto-entry values set (espeically the Serial ID) and the Holder record is then Dropped. (Of course, there would be an exlicit "DropHolderRecord" script step as well.) All actions for any Holder Layout have no effect (and throw an error) without a Holder Record being instantiated. All the pieces are there for FM to create this from what it already allows ($$globals on the fly and all). I am looking forward to being shown my error?... -- Sincerely, Brad
