I’m working on a custom event within Receipt Entry (this: Automatically set a Pack Slip on Receipt Entry - #4 by d_inman ) and when I’ve made changes to the event to handle the issue I was having with how I originally wrote it, then preview the changes in App Studio it works perfectly. But then when I publish the layer, Shift+F5 refresh the browser window on my Kinetic homepage, open Receipt Entry, and try it out again, it’s not behaving the same.
Specifically it’s passing the wrong pack slip into my REST call (which is the issue I’m trying to correct).
What it passes when I preview changes in App Studio (which is the new value my event is creating):
A while back, I was experiencing App Studio holding on to old values. I had a relatively long event chain where I would update a value (via row-update) and then perform some rest calls with that value. The problem was, it was performing the rest calls with the old value (prior to my row-update).
My buddy ChatGPT and I came up with the theory that: the row-update had completed from the action’s perspective, but the updated DataView value had not fully propagated to whatever expression/binding the next action was resolving.
We were able to get around this by splitting the event into multiple… and calling the rest actions with an event-next.
I know its a pain… but may be worth a test. I would take your event and split it.
Copy your original event… Give it a new name… then delete everything outside of the Green Square. Clear your trigger and just link up the no-trigger to the first rest-kinetic.
Copy your original event again… this time delete everything after the event-column-enable… and add an event-next to call the event you just previously created.
Disable your original event. (since we made copies, you still have your original in-tact, in case this doesn’t work).
Now test. See if breaking this up gets you around the “stale” value being passed to the rest call.
Dude, at the next Insights EpiUsers meetup, they need to give you an award for most helpful user on the forum. Your responses are always well written, detailed, often with having taken the time to try something out on your end first, and quite often spot on. I honestly don’t know how you find the time to be that active and detailed, while having (I assume) a full-time job, too.
Events also easily corrupt so I keep mine small and split them up with event-next all the time. It’s a PITA when trying to follow the logic path but worth it when one of them corrupt. Quicker tto rebuild an event with around 5 widgets than 20+.
So far I seem to have gotten it to work by adding in a pause (via a Function) and moving my column-enable, but if it continues to give me problems, then I may go this route. You’re right that it can be hard to follow the logic, but simple events are individually easier to understand (and I see Epicor taking this approach a lot with their events).
Easier to understand, but harder to follow sometimes when you’re jumping back and forth from a parent event to a bunch of event-next children with possibly their own event-next children
