We have here a number of use cases where an operator would like to jump to an auxiliary screen, e.g. to review some information, without interfering with the main process.
A common problem we have run into is the fact that any back-and-forth transition between such steps will inevitably re-trigger the “on step enter” triggers.
The only solution so far seems to be to add a pre-check to EVERY trigger which might accidentally be triggered in such a maneuver along the entire process, i.e. via a BOOL variable indicating whether the user is returning from such a helper step (TRUE) or arriving as part of the regular process (FALSE).
But this approach has proven to be very error prone and tedious to implement.
A much better solution would be to either be able to temporarily switch to another helper app without closing the original app session or a method which would prevent the “on step enter” triggers to fire, i.e. a “Goto step without firing on step enter triggers”.
another solution could be to add another step only for calculation.
The Calc-Step has on step enter triggers where the last one is a transition to your target step.
You could also add some exit triggers.
The target step has none or only always relevant triggers on step enter.
This makes it possible to navigate there with calculations (goto Calc-Step) or without (direktly goto target step).
The Calc-Step will usualy never be seen, because of the transition inside the step enter.
However you should add a previous and a menu button for sure…
I often did this and it is a compfy solution, because the triggers are visualy seperated and it works like a charm…
This would unfortunately require such a helper step at pretty much every step such a transition could occur… this is not really feasible unless you have a small app with only a couple of cases where such a jump can occur.
The app in question has 50+ steps excluding any processing-only steps. It would quickly become a maintenance nightmare.
I get you point, but I dont think the maintanance is bigger with an extra step then with a built in solution.
There are several decision options if the calculation is needed or not.
first call
source step
time
value of a variable or table record
…
it is quite easy to check any reason in the calc-step and decide if you should jump to the next step with or without calculation. It’s also easy to do a part of the calculation depending on a decision tree…
If the App is that big and you would need such feature in almost any step, I’m realy curious what the app is about and how it works. Maybe some steps could be done simpler (I often run into doing to much and to complex solutions).
You could also do some calculations on the trigger that goes to the step and reeeeequires calculation, so it’s not in the step enter trigger.
Another thing I often use is to make a trigger “If validation = true…” and copy that one … this is the base on all “step enter triggers” … the first one setzt validation on true and if any decision leads to “dont calculate further” I set this to false.
If you start working like this, Its almost no aditional work.
The nice thing about that is, that you can lead to interrupt at any point ( here the “throw an error by trigger logic” would help a lot).
I usualy use a combination of this and find this at least okay.
How would you imagin an in atep feature to be less maintanance, then the calc-step?
You could put the calc step and the target in a folder as well.
To implement those solutions afterwards is always some work. But that would be the same with an in Step solution.
You can easily copy the step, delete everything but the step triggers und add the transitions…
