Conditional not working ?

[dflachbart]

I am stumped by the following behavior I see in the SageMC IMDB code:



The "Person" branch gets executed (which leads to an exception because the object has the wrong type) although the conditional evaluates to "Title".

How can this be ?


Dirk

[GKusnick]

Remember that a conditional isn't an exclusive one-of-N branching. It tests all the branches in sequence, and executes any branch that matches at the time that branch is tested. So for instance if IMDBValue equals "Title", the Title branch will execute, and if as a side effect that code happens to set IMDBType to "Person", then the Person branch will execute as well, because by the time you get there its condition matches.

Could this be what's happening in your example? Hard to tell from here without seeing what happens under the Title branch.

[dflachbart]

Originally Posted by GKusnick

Remember that a conditional isn't an exclusive one-of-N branching. It tests all the branches in sequence, and executes any branch that matches at the time that branch is tested. So for instance if IMDBValue equals "Title", the Title branch will execute, and if as a side effect that code happens to set IMDBType to "Person", then the Person branch will execute as well, because by the time you get there its condition matches.

Could this be what's happening in your example? Hard to tell from here without seeing what happens under the Title branch.

No, the Title branch does not modify IMDBType at all. I actually added the IMDBType assignment in the conditional just for being able to print out the value in the "Person" branch without any side-effects (but this shouldn't matter to the problem since the code behaves the same way).

And even if the "Title" branch would hypothetically alter the value, then how would the debug log statement still print out "Title" ?

I am aware that all branch expressions get evaluated, but I would have thought that it is guaranteed that the chains below the expressions only get executed if there is a match. If the immediate child of the branch prints out a value that does not match the branch expression, doesn't it mean that it entered the branch although it did not match ?

Dirk

[GKusnick]

Right, I guess I missed the part about DebugLog printing out the wrong value.

OK, theory #2: For process (green) widget chains, everything you said is true. The code under a branch gets executed only if the branch condition is met.

For UI (blue) chains, it's a bit more complicated. I believe the menu loader goes through all branches looking for UI widgets to instantiate. They actually get drawn only if the branch condition is met, but since that can change dynamically after menu load (during animation or as focus shifts around), for performance reasons it has to eagerly instantiate everything at menu load time just in case. I have a vague recollection to the effect that some Java calls may get executed as a part of that eager instantiation.

I can't swear that this is what's happening in your case, but it sounds like a plausible guess. You could experiment with Trace to try to verify (or disprove) this theory.

[Opus4]

Did you put a debug statement right before the conditional, instead of after it, to check what it is really seeing at that point? Are there any widget references somewhere that could cause it to hit the wrong code? Try following it step by step in the debugger to see where it is going & what the values are.

BTW: ...DbPersonObject_getMarried() ... um, are you planning some new sort of service?

- Andy

[dflachbart]

Originally Posted by GKusnick

Right, I guess I missed the part about DebugLog printing out the wrong value.

OK, theory #2: For process (green) widget chains, everything you said is true. The code under a branch gets executed only if the branch condition is met.

For UI (blue) chains, it's a bit more complicated. I believe the menu loader goes through all branches looking for UI widgets to instantiate. They actually get drawn only if the branch condition is met, but since that can change dynamically after menu load (during animation or as focus shifts around), for performance reasons it has to eagerly instantiate everything at menu load time just in case. I have a vague recollection to the effect that some Java calls may get executed as a part of that eager instantiation.

I can't swear that this is what's happening in your case, but it sounds like a plausible guess. You could experiment with Trace to try to verify (or disprove) this theory.

Hi Greg,

I guess you were spot on ...

The tracer showed

PreDataUI         PersonPanel
PreConditionalUI  PersonPanel
PreEval           java call
PostEval          java call
PostConditionalUI PersonPanel
PostComponentUI   PersonPanel

After I safeguarded the java calls with another if IMDBType == "Title" below the branch expression the problem is gone. Your explanation makes sense, thanks very much for solving this mystery for me !

This looks like a very nasty trap when writing Studio code, and I dont remember seeing this mentioned anywhere in the documentatio. If so, I think it should be pointed out more clearly in the Guide that for UI chains not only the branch expressions, but also the widget code below the branch can possibly be evaluated any time.

Originally Posted by Opus4

BTW: ...DbPersonObject_getMarried() ... um, are you planning some new sort of service?

Honestly, this is just nielm's IMDB code ...


Dirk

[Opus4]

Did you have IMDBType initialized somewhere? If so, what is it?

Could its value have gotten changed somehow after the conditional?

- Andy

[dflachbart]

Hi Andy,

Originally Posted by Opus4

Did you have IMDBType initialized somewhere? If so, what is it?

I defined IMDBType as an atttribute of the menu, and it is initialized to "". Then the only assignment is in the top most widget you see in my screenshot by the java call.

Originally Posted by Opus4

Could its value have gotten changed somehow after the conditional?

No, it is only used in the conditional, and in the DebugLog widget.


Dirk

[Opus4]

The only thing I can think of also has to do with the multiple passes for the UI chains, and may not be any better than GKusnick's idea, but I'm fairly sure I've got UI areas that wouldn't produce anything valid & should cause an error if all their code were to be executed... but maybe only certain things get executed like this.

Try putting breakpoints before & after the conditional, where that variable is set & where used, then follow the trace when you enter that menu and the code executes freshly again. You can move a widget up/down & then move it back to force the entire menu to clear its cache & load completely fresh upon next entry.

I'm wondering if its value gets set, but then is cached. Later, when the panel is actually drawn, DbObject has changed so that the panel getting drawn is no longer the one you want. (Focus change, perhaps, w/o a full refresh of the correct area?)

Of course, if it is working, you may not want to bother tracing some more.

- Andy

[dflachbart]

Originally Posted by Opus4

I'm wondering if its value gets set, but then is cached. Later, when the panel is actually drawn, DbObject has changed so that the panel getting drawn is no longer the one you want. (Focus change, perhaps, w/o a full refresh of the correct area?)

I'll get the exception even if I do just one 'Person' lookup after a fresh UI restart. I'll double-check, but I am pretty sure the DbObject will only change on the next performed search, so caching a wrong IMDB type values seems unlikely.

I admit that the explanations so far are not 100% satisfactory for me either, and it's strange that very similar code in the default STV version does not exhibit this behavior

Originally Posted by Opus4

Of course, if it is working, you may not want to bother tracing some more.
- Andy

Yeah, and you might be right. I also find it most often very difficult and cumbersome to debug through UI chains since the execution sometimes jumps all over the STV (caused by various hooks), and the expression evaluator takes several attempts to print out a value, if at all ...

If I get bored I might spend some more time on this ...


Dirk

[Opus4]

You may do this one already... but for difficult to trace areas, I use several DebugLog() statements, like you did in the first post, to have them tell me what step I'm in so I can see exactly what order things happened in the log or on the console output.

- Andy