Unfortunately, the "Trap" is not foolproof.  It appears that it only works when the focus was previously on another form element.  If the focus is outside the form, changing the focus to element where one wishes to setup the trap fails to fire the On Element Entry event, thus avoiding the setting of the Trap.

As an example, I created a very simple Sesame application with three text elements.  The third element in the Navigation Order has a Trap, which gets set in the element's On Element Entry event.  When I bring up the form in Search mode, and find all records so that I'm in Update mode, the focus is automatically set by Sesame to the first element on the form.  Then I do the following:

1) Click on any menu item in the Sesame menu tree on the left side to take the focus away from the form.
2) Click directly on the text element that the trap is set on.

At this point, the On Element Entry event does not fire, so the trap doesn't get set, and thus I bypass the trap.  As a workaround, I added a trap set to On Element Immediate Change.  I can do this in my system because NULL is valid for the element in question.  But Sesame's Trap sample code can be bypassed by doing what I did above.

Of course, this problem is not specific to the Trap.  Any code that relies on On Element Entry can be bypassed by what I described.

MP,

Mark (The Cow) is 100% correct; forget about trying to control a user. (it creates more problems in the long run) I spent years trying to control (trap) how users interact and work with the application. It did nothing but frustrate me, the user and often in the users attempt to get around my trap would screw up the data more. After listening to Mark and Erika teach validate the data before committing it rather then control the user, I have found everyone is better off because there is less conflict and the data itself  (the main reason we wanted to trap the user) is much more accurate.

Well that’s my 2 cents for what its worth..

MP: We'll look into the On Element Entry not running if you move focus to the tree and back. There are protections in place to prevent this event from running multiply if, for example, On Element Entry pops up a message box which drops the user back into the element after it is dismissed. This condition may also be triggering that looping protection.

At any rate, setting the trap On Form Entry should handle this exception.

MP wrote on Dec 11^th, 2007 at 5:49pm:


As I said, we'll look into the tree exception.