It looks like the CallCheckForNeedsLotAttrs event also opens the app … have you run a trace to see which one is actually running?
Also/Or, the name “IterativeEvent” makes me think that it’s called by name from something like a dataview-condition event widget - maybe that’s not being handled correctly, and the calling event has to be updated to use your custom event
The initial event is when the onclick tool save is clicked.
I think I may have to go up the tree of events until I find the right one to replace.
the big parent I believe is UpdateOverride
the Iterative event is triggered afterwards by a dataview-condition.
after that it runs an event I put in before the CallchkforneedslotattrsUpd
the app-open event seems to come from the dataview-condition, “checklotattrs_iterativeEvent”
If i can’t override that event, Do i need to override the dataview condition as well?
That’s what I’m unsure of - I think it would be worth the effort to try: Copy the event with the dataview-condition and change the trigger to override the original, then change the one field in the dataview-condition to explicitly call your override of the checkLotAttrs_iterativeEvent.
That might work! with an Exit or Cancel at the end … but that might also mess with any other events that follow in the flow
I would check the trace to see what follows that might get cancelled