Jump to content

  •  

UPGRADE DEADLINE - SEPTEMBER 26, 2014!
FileMaker Inc. has a deadline for users of version 10,11, 12 as Individual box or volume licenses (with expired maintenance).
If you don't renew your maintenance and upgrade to FMP 13 you will no longer be eligible to upgrade, at the discount pricing.

Volume Licensing upgrade pricing for FileMaker Pro 13, FileMaker Pro 13 Advanced and FileMaker Server 13 will be discontinued.
Individual upgrade pricing for FileMaker Pro 13 and FileMaker Pro 13 Advanced will increase after September 26, 2014.
As of 27-September-2014, FileMaker 10 products will no longer be available for purchase or support.

http://help.filemaker.com/app/answers/detail/a_id/13865


Photo

How to intercept ''keystroke'' from value list?


  • Please log in to reply
3 replies to this topic

#1 K1200  old hand

K1200
  • Members
  • 588 posts
  • FM Application:11 Advance
  • Platform:Windows 7
  • Skill Level:Intermediate
  • Time Online: 20d 11h 23m 28s

Posted 30 January 2012 - 01:42 PM

I have a text code field that the user can override by selecting from choices in a drop down value list. But there are a few instances where, based on the content of the record, a change to the displayed code is not permitted.

I want to use a script trigger to intercept the user's selected choice before it changes the field's current value. The script will inform the user of the special case ... and the original code will remain.

I've tried OnObjectEnter, OnObjectKeystroke and OnObjectValidate ... but with each trigger, the code has changed (via the user's selection) before I can find out what it was.

I thought this would be a simple and common case, but if it is, I haven't found it. Among other things, I've read the detailed explanations on the SixFriedRice site, but they don't seem to cover the data cases my script encounters. As a fallback, I am able to restore the code using Undo, but it leaves the problem of determining whether it changed, or not. And the method feels shaky, not robust.

Thanks in advance for any help.
  • 0

#2 comment  consultant

comment
  • Members
  • 24,184 posts
  • Time Online: 328d 19h 20m 51s

Posted 30 January 2012 - 03:25 PM

See if this helps:

Attached Files


  • 0

#3 K1200  old hand

K1200
  • Members
  • 588 posts
  • FM Application:11 Advance
  • Platform:Windows 7
  • Skill Level:Intermediate
  • Time Online: 20d 11h 23m 28s

Posted 30 January 2012 - 04:01 PM

Yes, that's a good technique.

In my attempt to get something operational, I came up with this somewhat left-handed way ... also triggered OnObjectModify.

Set Variable ($IsNow ; Value:Table::Field)
Undo/Redo [Toggle]
Set Variable ($Was ; Value:Table::Field)
If [$Was = <Exception>]
  Show Custom Dialog ["Change Not Accepted" ; "<reason> "
Else
  Set Field [Table::Field ; $IsNow ]
End If
Your method is more deterministic ... because, as I mentioned, Undo/Redo seem to be open to "operational eventualities".

Thanks for the response.

BTW, one observation in working with both these methods: OnObjectModify triggers the script even if the object is set to its current value ... so "modify" is does not equal "change", but merely "field accessed by the user".
  • 0

#4 comment  consultant

comment
  • Members
  • 24,184 posts
  • Time Online: 328d 19h 20m 51s

Posted 30 January 2012 - 04:14 PM

BTW, one observation in working with both these methods: OnObjectModify triggers the script even if the object is set to its current value ... so "modify" is does not equal "change", but merely "field accessed by the user".


I believe "modify" means "edit". Re-entering the same value qualifies because the existing value is overwritten - it doesn't really matter by what. What does matter is that if the record was closed, it is now open and requires either reverting or committing.
  • 0




FMForum Advertisers