While working with Google Sheets’ onEdit trigger, I encountered an issue where the trigger fails to activate if a cell is edited but the value remains the same. This behavior occurs when a user re-enters the identical data during editing, causing no observable change. I need to know what alternative approach or workaround can be used to properly detect such events when a cell is open and the edit does not alter the existing content. Any solutions or insights on managing this scenario would be appreciated.
hey i used an onChange trigger instead and cached cell values to detect re-edits. it isnt perfect but works fine for my case. hope it helpd!
hey, i used a workaround that logs a hidden timestamp every edit. even if the cell value doesnt change, the timestamp updates so my script picks up the event. works fine in tracking re-edits if u dont mind a minor hack.
In my experience, when the standard onEdit trigger fails because the value remains the same, a practical solution is to incorporate the onSelectionChange trigger. This alternative captures user interactions even if no visible changes occur in the sheet. I developed a small script that monitors the cell selection and compares the edit attempt with a stored reference of the last input. This method requires managing additional state information and synchronizing between two triggers, but it reliably registers user actions that the onEdit event alone might miss.
In tackling this onEdit limitation, I discovered a method that revolves around setting a custom timeout upon cell selection, essentially forcing periodic value refresh checks. By inserting a small delay, you can programmatically recheck the cell’s contents even if the same value is entered. I implemented this by using an additional trigger that monitors for imminent inactivity following a cell focus change. This approach was not only effective in catching re-edits with identical values but also provided a buffer for more complex validations where immediate event capture is crucial. It has proven to be reliable in my projects.
I experienced similar issues with the onEdit trigger and found that switching to an installable change trigger can really help in catching these non-modifying edits. In my projects, I developed a workaround by comparing current cell values to your stored historical state, using either the PropertiesService or hidden sheet columns. This additional check not only registers the event even when the cell value appears unchanged but also provides more flexibility in handling user actions. It required some extra work to implement but has greatly improved trigger reliability.