I have a field with validation. How do I force to revert after the user closes or Okays the custom validation message?
I have a field with validation. How do I force to revert after the user closes or Okays the custom validation message?
If you're referring to the validation discussed in your last question, then use a script triggered OnRecordCommit. OnValidate will not trigger (and the validated field shouldn't even be on the layout).
Important:
Use script-guided action in addition to validation - not instead of it. Script triggers work at layout level. Data integrity should be maintained at the data level, independent of what measures may or may not have been installed on the current layout.
Ok. The field isn't on the layout, it is only used to check for duplicate, as we discussed.
wimdecorte it is not so much that I want to take it away that, I find it puzzles users more than help them: they start wondering what they are going to lose (in this case it is only one field in one row of a portal that must not be a duplicate therefore needs to be reverted. so why stressing my user with 2 prompts (1 is validation, 2 is FM default)?..
As I mentioned: if it is tied to a user workflow then don't do the validation at the schema level, but do it as part of the workflow, that way you maintain full control over what the validation does and how to handle it. It's what the event handlers are for.
Question. OnRecordCommit is at the layout level; how come it would work for a related record (layout is product, portal is price)?
(tiny voice) what are event handlers? Script triggers?
Cécile Savoie wrote:
(tiny voice) what are event handlers? Script triggers?
Yes, they handle an event (validation, modification, save, exit, entry,...) by triggering a script.
Cécile Savoie wrote:
Question. OnRecordCommit is at the layout level; how come it would work for a related record (layout is product, portal is price)?
If the field that is being modified is on the layout then you can select what events you want to handle by script. Doesn't matter if the field is from a related record, as long as it is on the layout.
Ok cat got my tongue. Can't figure out what to put in the script. Everything I tried deletes the first occurence or the validation fires.
When the OnRecordCommit gets fired, the focus isn't in the field or even the portal row that was the last modified which is the one that we want to revert if there are duplicates. The test works ok but since I can't figure out how to go to the record and field which I want to set to ""...
I am not sure what exactly you want to happen when a duplicate is detected. The only thing I can say with some degree of confidence is that if you don't want users to see Filemaker's native validation dialog, you must detect the duplicate yourself before attempting to commit. This is because:
Cécile Savoie wrote:
Question. OnRecordCommit is at the layout level; how come it would work for a related record (layout is product, portal is price)?
There is a reason why the script step is named Commit Records. When you commit a parent record, you also commit any open records in portals.
I want to detect the duplicate and set the new entry that causes it to "" so that the validation of the test field which is not on the layout doesn't fire.
I don't know how to script that. I tried for almost 3h yesterday and all I am able to achieve correctly is detect the duplicate. I don't know how to work (remember row, select row, set a field on that specific row,) with portal.
It's not simple to do this in a portal. And it's not simple to work out what the rules should be for such action: do you correct the last portal row that is a duplicate of another? What if the user accidentally modified a historic price?
I would look for a solution where the user entry itself is scripted.
What about presenting only a set of valid (allowed) choices to the user. This would spare you all the validation business and give users a better experience.
My initial question was how to deal with this situation "Semi" unique value; validation or prevention . Michael offered a way to validate. I stumbled on the revert prompt, which I did not like hence the current thread.
You suggest a way to "prevent". My first thoughts on this were "is it possible, and if so how, to prevent values that have already been selected to be available in the drop down menu?"
I was initially happy with the validation path until I stumbled on the double prompt.
It is funny how some trivial things turn out to require a rethinking because there isn't straight forward ways to address/prevent them.
It's not simple to do this in a portal. And it's not simple to work out what the rules should be for such action: do you correct the last portal row that is a duplicate of another? What if the user accidentally modified a historic price?
Indeed, initially I was using the max(ID_Price) to target the last created record; but then I realized that the user could in fact be changing, willingly or accidentally, the value on a previous row, in which case it would not be the last one created...
I will look into a little pop over to have a process circumscribe the entry in this field.
Cécile Savoie wrote:
Ok cat got my tongue. Can't figure out what to put in the script. Everything I tried deletes the first occurence or the validation fires.
When the OnRecordCommit gets fired, the focus isn't in the field or even the portal row that was the last modified
Which is why you shouldn't use the OnCommit to handle a validation issue, that's what the OnValidate is for... Using OnCommit assumes that you are past the validation phase and it is not the cleanest way of handling this.
wimdecorte wrote:
Using OnCommit assumes that you are past the validation phase
That would be ideal - but it doesn't work in this case. As was already explained above.
It doesn't work under the constraints explained but I think the constraints don't need to be what they are. It would take a bit of a rethink but ultimately would be cleaner IMHO.
In my experience, every time you find yourself using something for what it was not meant to be to circumvent something else, it is a signal that that it may be good to take a few steps back and not solve the problem right in front of you but a problem upstream.
wimdecorte wrote:
I think the constraints don't need to be what they are.
I'm all ears.
It starts by removing the validation from the field definition and moving it to where it fits in the workflow.
I don't know enough about the solution or the desired workflow to offer much beyond that, but that's where it starts.
Clearly the field-level validation gets in the way so perhaps it doesn't fit where it is.
Cécile Savoie wrote:
My first thoughts on this were "is it possible, and if so how, to prevent values that have already been selected to be available in the drop down menu?"
How about the attached example? When you select a value, the relationship no longer includes that value so you can't use a popup menu showing only the second value. This may not be a problem for your application, but if it is then you can deal with it as I did in the example. Use a dropdown list format, pad the field contents out of sight and stack a calculation field on top of it which shows the human readable value (set to not allow access to the field). Stacked fields won't work in web direct though.
----edit----
I just realised that it was acting correctly only with progressive records. Incorrect values were shown when going back to previously created records. I added a reference to the ID field in the List key field calculation and an on object enter script that sets the ID to itself, to force the list to update. Seems to be working correctly now.
The normal course is that the user has the choice of fixing the error or reverting. Sounds like you want to take that choice away. Look into handling the OnValidate trigger and remove the validation from the field definition itself.