Unexpected dependency of an output target of a process on the process' structure

andreic

Hi all,
I'm getting unexpected behavior for opening a form using a process with the output target set to new tab:

when the process includes just one rule with several IF .. ELSE IF .. ELSE IF .. statements, the form opens in a new tab as expected, no problem (see note)
when the process includes separate rules with separate IF .. ELSE IF pairs (as is apparently recommended to do instead of long IF .. ELSE IF chains), then the form always opens in a popup instead of the expected new tab.

There is really nothing else factoring in except for that process structure. I've changed nothing else except for that. Same actions, only broken into several rules instead of one single rule with a long IF .. ELSE IF chain. That's the only difference.

Is this a known limitation? Any ideas if this can be fixed somehow?

Note: Related to this is the reason I had for breaking down the long IF .. ELSE IF chain - I found that it just doesn't evaluate the last ELSE IF conditions, as if the chain is "too long" for it to handle. No warnings or error are given for this. Is the limitation of the number of ELSE IFs specified somewhere?

PointsWell

It sounds like you are doing additional processing after you have a DISPLAY. If your process continues to evaluate rules then the output will be a pop up.

If you have a long complex process then you are better to break it out into sub processes to ensure that you only traverse a branch once before reaching an end to the process.

See https://www.awareim.com/forum/post/53012

For example if you wanted to evaluate red cars, registered in New York, you could check

IF Vehicle.Type = 'Car' AND Vehicle.Colour='Red' AND Vehicle.RegsiteredIn='New York'

This is a complex statement to evaluate. To simplify it you could evaluate

IF Vehicle.Type='Car' THEN CheckCarColour ELSE
IF Vehicle.Type='Motorbike' THEN CheckBikeColour

Process Check Colour would then be

IF Vehicle.Colour ='Red' THEN CheckCarRegistration ELSE ...

Process Check Car Registration would then be

IF Vehicle.Registration='New York' THEN DISPLAY Vehicle USING FormName

There is only one route to the DISPLAY in the nested process route.

andreic

I see. Thanks a lot for the explanation.

"If your process continues to evaluate rules then the output will be a pop up"

I guess that says it all, though I would still classify this as undesirable behavior.

By the way if it helps, I tested and the maximum allowed number of ELSE IFs seems to be five. The rest don't seem to get evaluated.

PointsWell

andreic wrote
"If your process continues to evaluate rules then the output will be a pop up"

I guess that says it all, though I would still classify this as undesirable behavior.

Logically display must be last because if there's more processing you could potentially be further modifying the thing you've displayed (I suppose)

By the way if it helps, I tested and the maximum allowed number of ELSE IFs seems to be five. The rest don't seem to get evaluated.

I have longer chains, 10 or more ELSE IFs and they can then branch easily into sub processes, the key is to keeping the evaluations simple because AIM checks every condition and then checks the inverse of those. If the condition is complex it will become very complicated working out all the true and false versions of the evaluation.

Keep evaluations simple, branch the, out over multiple sub processes and structure them so that there is only one journey through the branch.