trapping user input

[reguila]

Is there any way to trap the user's 'OK' or 'Cancel' input. I need to perform different housekeeping routines before exiting from a script that allows the user to edit records, depending on whether the user hits OK or Cancel, so I want the script to continue after the Pause/Resume script [indefinitey] script step. Hitting OK allows this to happen, but if the user hits cancel it exits all scripts and bypasses the houskeepine routines. I need to trap the Cancel in some way therefore, so that I can over-ride it and route the script appropriately.

I'm new to filemaker, but have long experience of Omnis which provides a numerous event trapping options for dealing with this sort of thing, and I would be astonished if FM does not provide a Get() function of some kind to trap and interrogate for basic events like this. I must be missing something very obvious, but I can't see it at the moment.

[comment]

See if this helps:

http://fmforums.com/forum/showtopic.php?tid/193520/

[reguila]

Thanks.

If the info in that thread is correct, then it seems there is no way to trap user "OKs" or "Cancels", which would be an astounding limitation of FM.

I have just been trying to make a temporary work around using Cancel and OK buttons calling separate housekeeping scripts but hit a related snag in that I cannot see any way in FM to insert an 'OK' or 'Cancel' into the FM event queue, so as to get past the Pause/Resume step, i.e. FM continues to wait for an OK or Cancel until one or other key is hit.

Maybe I need to ask a more general question: How do other people manage to script the monitoring of user input generally, so as to control housekeeping tasks, without getting into this catch 22. If I turn off User abort, that defeats the whole object of the exercise - like cutting off one's head to cure a toothache!

[comment]

The buttons are actually labeled "Continue" and "Cancel". I mention this because it emphasizes their purpose. They are there to give the user an opportunity to either continue a paused queue, or - if the developer permitted this - to halt ALL scripts. They are NOT designed to capture user input (that's what Custom Dialog is for).

Capturing "Cancel" would be rather useless anyway, because the result of the action is that there are no scripts running. So what exactly would we do with this information?

In normal operations, an unsophisticated user would have the entire status area hidden and locked. It would be revealed only in Preview mode, and the only option there would be to continue. Everything else would be handled by buttons placed on the layout.

I can't tell from your description what exactly your issue is. I suggest you examine the various options for dealing with "Current script" when defining a button to perform a script.

Edited October 19, 2008 by Guest

[reguila]

Thanks for the further input, and sorry - not sure if I am being really dumb (entirely possible) or whether our wires are crossed. Whichever, I do greatly appreciate your help and would dearly like to get this problem sorted.

I am presuming that the Continue & Cancel buttons you mention are the ones which appear in the status area. However, I need to hide the status area because if the user has access to the record navigation controls it unpicks my housekeeping routines that track the user's navigation between layouts, and records.

Not sure how I could use realistically the custom dialog for editing records.

Basically, I need to allow the user to edit records but I also need to log changes and provide an audit trail to provide a facility to roll-back to, and reload, previous record states if needed – essentially to provide an undo capability. I therefore need to control the edit process tightly, and was planning a script sequence to achieve this roughly as follows:

User selects record to edit in a display-only layout, and clicks an "edit" button to initate my "edit" script sequence which does the following WITH THE STATUS AREA HIDDEN:

1) Captures the current layout, filter state, and logs them so that afterwards I can return the user's screen to his pre-editing state.

2) Creates a duplicate of the record before it is changed, for roll-back and audit purposes.

3) Switches to an "edit" version of the "viewing" layout, with enterable fields etc., plus (my own) Cancel and OK buttons.

4) I then want the user to be able to make the changes he wants to the record, and on completion to be able simply to hit the enter key, OR the cancel key, OR hit the OK button, OR hit the Cancel button.

5) Depending on whether the user has OKd or Cancelled (whether by keystroke or hitting the buttons) I need to be able to intervene at that point to finish the housekeeping – by appending the audit-log (roll-back) copy of the original record, or to use this copy to revert the record back to its original state if the user has Cancelled; then take the user's screen back to the original state before he started his edit, and showing the edited record.

All of this would have been routine in Omnis as it provides "OK" and "Cancel" buttons that generate the appropriate event, plus event trapping faciliteis, and access to (and control over) the event queue itself. I just can't figure at the moment how to do the same in FM 9. I have managed to get some way towards what I need by effectively dispensing altogether with the keystroke cancel option (setting Allow User Abort to No), and relying on my own OK and Cancel buttons, but is is messy and I am sure there must be a neater way. I have no doubt that my previous OMNIS mindset is not helping, but there is a lot to like about FM and I am keen to learn.

[comment]

I have managed to get some way towards what I need by effectively dispensing altogether with the keystroke cancel option (setting Allow User Abort to No), and relying on my own OK and Cancel buttons, but is is messy and I am sure there must be a neater way.

I don't know of a better way. Your only mistake, I think, is that you assumed the Continue/Cancel buttons in the status area can somehow help with what you're doing.

See also here:

http://fmforums.com/forum/showpost.php?post/304404/

for an elegant way to branch a paused script according to user's choice.

BTW, Filemaker has a built-in mechanism for reverting edited records. If you disable automatic saving of changes (in Layout setup), users have to commit edits expressly.

[bcooney]

You may wish to check out WorldSync's Audit Log product, FMDataGuard

I remember my days working with FoxPro. It had this one command that I'd love in FM, "scatter memvars." It would create variables of every field on a layout in one step! Then, depending on Save or Cancel, you either closed the window and wrote the memvar value to the field (Save) or just closed the Window (Cancel).

To accomplish this in FM, you'd create global fields for edits. You'd pop a custom layout with the global fields, and populate them with the current field value (using SetField) and pause. "Save" would use the Set Field script step to write the new values from the global to the actual field. "Cancel" would just close the window.

hth,

Barbara

Edited October 19, 2008 by Guest

[reguila]

Many thanks for all you help with this. I have at last managed to get something together that works tolerably well now, and is reasonably fast. At least I know now not to waste more time digging for event trapping that does not exist.

I did consider "disabling save changes automatically", but I felt that the resulting dialog would rather get in the way of user (I hate dialogs except for real exception cases).

[reguila]

Thanks BCooney. I will look into the product you mention, but brain has just turned to mush now and will approach it when I am a bit fresher.

I have never used FoxPro but their approach sounds excellent. Omnis does something similar in that copies the current record into a buffer for editing/inserting new and then commits only when you hit ok, but of course you have to explicitly copy to variables if you want to keep the buffer contents in the interim.

[comment]

I did consider "disabling save changes automatically", but I felt that the resulting dialog would rather get in the way of user

There are ways to disable the dialog, for example by placing an empty web viewer in the background.

You need to consider very carefully what the implications of your method are in a multi-user scenario. Allowing one user to edit a record in a "sandbox", without locking the original away from other users, is a recipe for potential disaster.