Thank you for your post.
According to Development, if a variable is used in a find request but is not a known variable, then it will not be expanded. This often results in an alert complaining that no matching records are found, since it is unlikely that a variable (like $test) will match anything in the database. This behavior is intentional to allow users to identify variables that have not yet been assigned or have a null value.
In your case, put an IF clause around the find request. Using your PerformFindTest script, it may now read:
Set Variable [ $test ; Value: Get ( ActiveFieldContents ) ]
If [ not IsEmpty ( $test ) ]
Perform Find [ Restore ]
The other method with entering Find Mode sets the field to the contents of the variable, so this returns a different error message. Regardless, I can see how this can be deemed inconsistent, so I have sent these examples to Development and Testing for review. When I receive any feedback, I will let you know.
Even with the second example, consider using an IF clause to check the contents of $test.
Sorry for the delay in replying and I was amazed to see that this behaviour also existed in FileMaker 11.
Your comments make sense, but this bug was resolved somewhere between v7 and v10. More importantly, a scenario where it certainly can cause problems is when AND finds are set in Perform Find in both new files and more worryingly change the way legacy systems work.
In the example screen shot of a failed find we had Perform Find set to:
Find Test::FieldA with a criteria of $testA (set to 'Dog')
AND Find Test::FieldB with a criteria of $testB (set to null)
The screen shot shows that FileMaker is trying to match both 'Dog' and '$testB'. What it should be doing is finding on 'Dog' in Field A and null in Field B - this leads to a completely false result. Using Enter Find Mode using exactly the same variables results in a correct search where records containing 'Dog' are found and no search is performed in Field B.
I do appreciate that we could overcome this by using 'If'. But surely it is a bit mad having to wrap every variable before you use it within a Find request. For instance our 2 criteria Find would have to have 4 separate Perform Finds to cover the A empty B not, B empty A not, both empty, both not empty - imagine this with 4 or 5 criteria set!
I still maintain that this is a bug that has returned from old. We have 2 Find systems that can produce different results using the same variables - hardly consistent behaviour.
We have solutions that have been upgraded and enhanced from original development in FileMaker 7, when we always used Enter Find Mode, Perform Find as we were aware of this bug, which was acknowledged, documented in a FileMaker update release and cured in later versions. However, once this was resolved we have used the convenient single script step of Perform Find and this behaviour could easily provide incorrect results running these systems in later versions of FileMaker.
Looks like we're now going to have to revert to FileMaker 7 techniques!
Or perhaps Phil an additional category in the script steps 'Work Properly' and 'Don't Work Properly' ;-)
Just suggesting a work around that works right now and one I consider a better way to script finds in the first place.
Appreciate that Phil, as does using Enter Find Mode, Set Field and Perform Find without restore. Just didn't expect to have to worry about solutions previously written after this specific bug was solved years ago.