Your post reveals numerous problems. The most serious of which is that you are using a repeatilong field to list your line items. Use a related table with a portal to do this. It's simpler, more flexible and the import records tool comes with an option that makes it easy to move your data from a set of repeating fields into a group of related records.
Next, OnObjectModify doesn't do anything but what you program its script to do. So if it modifies all records, that's due to what the script was set up to do. You might have s replace field contents step in that script for example.
And you then say "it seems to think that an empty field receiving data is a modification". Well that IS a modification and is exactly what one if your staff might do if they start to edit the record, say to add another line item. So you need to explain what you mean here.
Forgive me, my language may be really basic and even wrong because I am in the very early stages of understanding this side of FMP. I've been at this company 5 years and have just been tasked with learning how to make changes.
I can confirm that my "repeating field" for line items, is in fact- a related table w/ a portal after all. I can see that the inventory items pull from a related table.
I want FMP to almost take a snapshot of the initial data entered- so it can recognize when something in the field has changed. Is there a way to tell FMP to know what the data was upon entry vs. what it is upon exit- and then triggering a change in the radio checklist field? My problem is knowing what language to use to make these things happen. I'm as clueless as they come - even though I've taken a few online courses. Nothing I've learned puts these kinds of problems/goals into context. Thanks in advance for your patience!
I do have a client with a similar situation. In their case, one person fills out a purchase order and another person prints it and disburses payment. Problems arise when the first person discovers that they need to add another line item at the same time that the cashier tries to print the record.
My solution was to use manage security to block editing a record once its status was changed to "Ready for Cashier". If such a tag needs to be modified, they click a button that changes the status and then this allows them to edit the record.
OnObjectModify, OnObjectSave, and OnObjectValidate are not tripped unless new data has been entered. And no such snapshot of the data is needed.
But you still have not explained how entering data into an empty field isn't actually modifying the record.
So from your experience, there isn't an easy way to change the selection in a radio checklist based on the modification of another field? I was hoping there was a simple script that could send the checklist from Complete to Edit! Upon a quantity or description change...
Locking an order from being edited once marked as "complete" wouldn't really aid the office in any way. We'd still have to manually select "edit!" from the list instead- which is something they often forget resulting in an incomplete order either right before departure or upon arriving on location.
Thanks so much!
I understand that entering data is technically modifying the record- and it's not the end of the world if doing that triggered the "edit!" status- but from what I had seen- setting objectmodify for this particular field had a universal affect, not a per record basis. I wouldn't want all 100 records to switch to Edit! because I have modified one field on one specific record.
To repeat, NONE of these triggers do anything but perform a script that YOU create that does what YOU design the script to do. If it has a "universal effect", look at what the script does, not the trigger used to perform it. You can post a script here in the forum by taking a screen shot of it while open in the scripts workspace and using the picture tool in the tool bar above to insert it into your reply. You can also copy/paste the script as text from either a Database Design Report (requires FileMaker Advanced), or from a PDF of the script.
Speaking of FileMaker Advanced, I strongly recommend that you get a copy if you do not already have one. Enabling the script debugger, then tripping your script triggers and stepping through their scripts one step at a time could teach you a lot about how a script does or does not work.
It is quite easy to modify your radio button field. Set Field does that. Commit records then makes the change visible to other users by saving the change back to the file.
But you may find that this change alone isn't quick enough to do the job. That's part of why I recommended a different approach. The other reason is that using Manage Security to control the ability to edit the record based on its status avoids having to set up script triggers on every such field on the layout.
I understand that entering data is technically modifying the record- and it's not the end of the world if doing that triggered the "edit!" status
How about you answer the question that I've asked here. WHAT makes this different from any other user action that modifies the record? From where I sit, it makes no sense to not treat that as any different from editing a field that already has data. I'm concerned that there may be a work flow issue here that could make my suggestions fail to work for you.
You are correct, I should not be treating this field any differently than I would any other when it comes to data entry because, it isn't any different. Whether the field is empty or already has data in it- the concept is the same as it would be for any other field on the layout.
I'm sure I am making this more complicated in my head than it needs to be.
I apologize, I am clearly out of my depth here! It's just the "most important" section of the layout because that's where we define, itemize, price each and every rental- otherwise, its all the same. I appreciate your guidance, clearly I'm not the sharpest tool in the shed!
So far, I've gone to set a script trigger to the description field -
1. Set Field [ Invoices::Prep_Status[Invoices::Prep_Status = "Edit!" ]
2. Set Field [Invoices::Prep_Status[Invoices::Prep_Status_Audio = "Edit!"]
Commit Records/Requests [with dialog: off ]
But upon editing the field, nothing happens w the radio checklist.
Both of your set field steps have been set up incorrectly and show two common beginner mistakes. They should read like this:
1. Set Field [ Invoices::Prep_Status ; "Edit!" ]
2. Set Field [Invoices::Prep_Status_Audio ; "Edit!"]
The extra set of brackets indicates that you put your calculated expression into the repetition box instead of into the "calculated result". In the scripts workspace, click the gear, then click specify to the right of "calculated result" before entering the calculation ("Edit"). do not enter the semi-colon as that's just a display character added by the application.
And you just need to specify the text in quotes. When you enter an expression such as: Invoices::Prep_Status = "Edit!" Your are comparing the value of Invoices::Prep_Status to the quoted text "Edit!". If the values are equal, this evaluates as 1 (True). If they aren't, it evaluates as 0 (False).
And line 2 is either redundant or specifies the wrong target field.
Thank you this fixed the problem. The second field is in there because we have two diff status checklists depending on what the order calls for.
Much appreciated. I'm sure I'll be posting more questions
Asking and answering questions is the reason that this forum exists.