Fred, I don't understand how your work around is supposed to solve the issue.
I have, in some cases, worked around this issue by passing the value of the field to the OnObjectEnter triggered script as a script parameter. That way, my script can access the value of the field before the value list "pick" modifies it.
I don't know why, but it works around very correctly :
If your object is only triggered like this :
• OnObjectModify -> YourOnModifyScript
--> IT FAILSBut, If you object is also triggered like this :• OnObjectModify -> YourOnModifyScript• OnObjectValidate -> YourFakeScript (that only contains a comment)
--> IT WORKS
So, it seems that if another and following event is fired, the OnObjectModify trigger behave correctly even the object's type is a drop-down object.
I'm not seeing any difference in behavior.
I took a drop down list field (no arrow option) on a classic theme layout.
Assigned a script that just opens a custom dialog as it's only step to be performed by the OnObjectEnter trigger. THen assigned the OnObjectValidate trigger to perform the "do nothing" script.
I entered browse mode and tested by clicking the field.
Then I removed the OnObjectValidated trigger and tested again.
In both cases, the valuelist deployed in a brief flash followed by the custom dialog appearing.
I then changed the first script to set a global variable to the contents of the drop down field. Again, whether I included the OnObjectValidate script or not, I got the same result--The drop down deployed I made a choice, but when I checked the variable, the value of the field before the drop down pick changed it was stored in the variable.
By any chance were you testing a POP UP menu instead of a drop down list?
Hum, Phil :
I didn't complained about OnObjectEnter trigger.
I complained about OnObjectModify trigger.
And Yep, i tested Pop-up menu objects and they behave correctly.
Maybe my english is -again- too bad in discribing finest FM behaviors or bugs. And i'm sorry.
But now that I've tested OnObjectModify, I still don't see where this is "broken" nor do I see any change in behavior when I select the OnObjectValidate trigger to perform a "do nothing" script.
In both cases (Set variable or show custom dialog), I see the same behavior and it is the behavior that I would expect.
Please note that onObjectModify will be tripped for each keystroke of the field if you type in data into the drop down list and that this is also expected behavior.
The targeted point of this post is : the active field (object in fact) changed BEFORE the script was triggered !!!
In other terms, the focus has changed before the script's execution. And that is my problem !
Thus, several functions as Get ( FieldContent ), that are really concerned by this trigger, will not working as expected as long as the active field is not the same that invoked the trigger.
(I am a poor lonesome cowboy... la la la la la.)
I had to re-read your original post to get it, but yes, this also happens in Windows 7. (And your workaround also works.)
Thank you for the post.
I am able to replicate this behavior in FileMaker Pro 12.0v4 regardless of the operating system. To replicate perform the following actions:
1. Create a new database: One Field, New Value List (One, Two, Three)
2. Place field on layout as 3 types (Edit, Drop-Down, Pop-Up)
3. Name the layout object fields using the Inspector (1, 2, 3)
4. Set OnObjectModify script trigger on all 3 fields
Set Variable [$var; Value:Get ( ActiveLayoutObjectName )]
Show Custom Dialog ["What Number?"; $var]
5. Change the value in each field
Drop Down Field: 2
Edit Box Field: 2 (after each keystroke)
Pop-Up Field: 3
When modifying the Drop Down Field, the expected result is 1 because that is the field object's name. I also discovered in testing that the tab order (Edit > Layouts > Set Tab Order) matters. The expected stack order is Modification, Triggered Script, Next Tab Location; however, when the field type is a Drop Down, then the order appears to be: Modification, Next Tab Location, Script.
I forwarded a report and this entire thread discussion to Development and Testing for review.
Thank you for the post.
Our Testing department had a previous report (not through the Forums) of this issue. Testing and Development is aware and confirmed this behavior. Additionally, I added your comments to the previous report.
Thank you for posting a workaround to help others who might encounter this issue.
This bug have not been fixed on FileMaker 12.0v5.
This bug has not been fixed on FileMaker Pro 13.