You describe a mixture of script and manual find interactions that make it difficult to picture the context of what you want to do here.
You describe entering find criteria manually, but also mention set error capture and the lack of an "error number"--which are script features.
Perhaps you have a script that enters find mode and then pauses for users to specify find criteria?
If so, the behavior you are describing happens while the script is paused. Since it's not running at the time a user enters the criteria, there's no way for it to respond to any error conditions until the script is continued.
The rest of what you describe would then seem to be normal Filemaker responses to incorrect data entry while in find mode. Can't quite see how this would "ruin" a user's experience? The operators are not "invalid" by the way, you're getting an error message because those operators also require the user to enter a value along with the operator. Thus, entering just < will be invalid, but < 100 will not be.
Thanks for the quick response.
This behavior happens in either a manual find (if you click out of the field) or a custom scripted find (if you click out of the field using FM's native drop down list from the Status Toolbar or if you use a custom value list attached to the field via Field Setup.
The only four find operator characters FM objects to are the < ≤ > and ≥ and the error dialog pops up before the user can even type in any additional criteria. So if a user selects one of the other find operators they can just type in any additional criteria without getting the error message, but if they select on the the four they get a different response from FMP. So maybe "ruin" is overstepping, but to me this to me is inconsistent behavior on FM's part.
The four operators you list require additional data after selecting the operator.
I can enter find mode. Enter a field. Enter or select one of these operators and no error message pops up until I exit the field without adding a value after the operator.
When the error message pops up, I have the options Revert Field, Yes, No. Revert returns the field to its previous value. Yes accepts the invalid criteria. This option allows me to leave the lone operator in the field and add the missing value later. No returns me to the field so that I can add the missing value.
This seems like reasonable, normal filemaker behavior. I don't have what your are reporting: "...the error dialog pops up before the user can even type in any additional criteria..."
That suggests something else is going on. If this is Filemaker 10, do you have any script triggers set on the field?
Regardless of version, if you create a brand new layout, do you see this same behavior?
This happens both when using a manual find, selecting one of the four offending operators from the Status Tool bar and then clicking out to the field; and when using the scripted find and selecting one of the four offending operators from the Status Tool bar and then clicking out to the field OR using the custom value list to select one of the four offending operators. The dialog pops up immediately even though it appears that the cursor is still in the field, since if you accept it by clicking on Yes it takes back to the field and the cursor is right behind the previously offending find criteria character.
I did create a new file and got the same results, I have used this Find script for sometime and it works perfectly. But the gentleman who signs the check wanted to know where the find symbols were as I locked him out of the Status Toolbar and I tried to provide them via a value list, which works quite well except for the four less than/greater than characters.
Well all I can say is that I've been using many versions of Filemaker for many years and simply have never seen this behavior. The error message is not supposed to appear until you exit the field. As long as you do not, this message should not appear.
Testing a brand new file rules out possible layout/file corruption.
Can you test this on a different machine?
I'm guessing here, but perhaps you've got a problem with the specific computer you are using.
This problem does occur when I click out of the field, but only for the four named characters.
It also occurs when I use a value list to enter the characters, even though the cursor does not appear to ever leave the field. Maybe selecting a value from a value list is akin to clicking outside the field.
I am on the way to the client's office to try everything anew on their machine. Looks like maybe I should give up the fancy stuff and just put a text listing of the find operators on each find layout.
OK, that clarifies things.
"This problem does occur when I click out of the field, but only for the four named characters."
This is expected behavior as these are the operators that require additional input from the user to form a valid search criterion.
"It also occurs when I use a value list to enter the characters..."
That's it! I expected that for a pop-up menu, but am suprised to discover that this validation is also triggered when using a drop down list.
The work around here is to create a search layout with global fields. The user enters their criteria while in browse mode and clicks a button to trigger a script. The script then uses the data entered in the global fields to build find requests, perform the find and display the results.
As a result of this thread, I have posted a bug report in the report a bug forum:
While experiements with an old install of FMP 5.5 suggest that this is long standing behavior. This appears to me to be a significant enough interface inconsistency to merit such a report.
Thanks again for your assistance. Your diagnosis was correct and I agree that this is inconsistent behavior given that other operators need additional parameters but don't call up the error dialog. Sadly the global shadow fields didn't work in this instance, I guess I'm just lucky that in all the dbs that I have used this script in the past no one ever asked for drop down find operators before now. I'll file a bug report as well.
No need for two bug reports.
The global field approach will work if you set it up correctly. If you want to try that approach let me know and I'll help you set that up.
The bug report specifically deals with the premature validation check and then TSGal and I discovered even more inconsistency when using a validation rule on a drop down list formatted field while in Browse mode.
The other operators form valid search criteria by themselves.