altering variables and process chains and UI Chains..

[jbuszkie]

Ok... Slowly making progress..

I have this chain that takes an airing and checks to see if it was recoded on a digital tuner so I can mark it as a digital recording. Now there are two different ways I want to mark this so instead of going through the whole copy of the chain again, if figured I'd set a variable. This is where my problems start...

If I go through the process of checking the airing and I just set the variable "IsDigital" with out doing any UI stuff, the chain turns green (which should be a process chain right?) but then the chain never gets executed. I'm sure there is a reason for that which I can understand at the moment.. but... If I just put the shape UI widget in the process it turns blue and gets executed but when I try to access the variable in another chain below, it still has the initialized value, not what was set in the other chain. Now if I add a text widget and actaully display the contents of IsDigital then everything works like I would expect it to (But I'm not supposed to use UI widets in a loop, right?). Why should this matter? Now I do initialize the variable as one of the top children. According to the manual if I use the attribute widget it should be accessable under a panel... Which is what I'm trying to do.

The easy solution is to just copy the whole chain to the action widget below and recalculate. But I thought this was stilly since I've already calculated it and could waste cycles..

But I'd like to understand why it's not working like I expect it to... (and yes I've read the manual..)

Please see attached code snippets..

I hope you guys can understand what I'm asking!!

Thanks!

Jim

[Kanati]

It SOUNDS like a variable going out of scope, but I'm not as handy with studio as to be able to tell for sure.

Too much work right now for me to actually dig into studio like I would like to right now. Hope someone here can answer your issue in short order...

[Narflex]

Try using the debugger or tracer in the Studio and that should shed some light on what is getting executed when so you can see what your code is actually doing.

[jbuszkie]

I am using the debugger and tracer..

Maybe I don't understand how this how whole process vs. ui chain works with variables...

Attached is a "slightly" modified version of the tutorial.

Go to The action widget tutorial (#7) and load and expand the whole menu.

1. As it is... If you load the menu you see "Testing 1 2 3 4 5 6 7 8 9 9 9" Why is there three 9s?? Why not one? How is it going through this 3 times? Also when it prints it again a little lower there are only 2 9s?

2. If you delete "REM Look here" widget the chain turns green and when you refresh it doesn't seem to touch the variable as if it didn't execute the that process chain? If it isn't going to get executed, then why didn't it turn yellow?

Maybe one of you experts out there can explain it to me.
If I can understand this then I can probably figure out my original problem!

Usually I can just play around with things and figure it out for myself, but this time I cannot!

[nielm]

Blue is an action chain leading to a drawing object, which will be executed when drawing the screen...
Green is an action chain only executed as a result of an *event*, which in your case would be clicking the recording item...
(yellow is never executed)

You need to add an indicator -- so you definately need a widget chain that gets executed when rendering (blue), so you need a widget chain that *ends* in a drawing object.

You can use certain UI widgets in a loop -- the problems come when you want the loop to generate multiple instances of the widget: it works for shapes, but not for other UI widgets,

In your case, the loop is just a 'calculation' loop... so what you need to make it work is a single UI text widget as the child of an If (false) widget as the child of the 'else' child of the loop condition.

This makes the loop look like it ends in a text widget, so it will be evaluated during rendering.

item2=0
If item2 < Size (DeviceInputs)
+- > true
    +- REM loop stuff
    +- item2=item2+2
        +- REF To if item2 < Size (DeviceInputs)
+- > else
    +- If (false)
         +- (text) untitled

put this type of construct on your item and item2 loops, and it will force both loops to be run at time of rendering, so that your variable will be set for later use... Because the text widget is a child of an If (false) it will never actually be drawn.

(similar code is used in the disk space bar widget in the main menu to force widget tree evaluation at rendering to set variables).

Hope this makes sense!

[jbuszkie]

Ok.. This is starting to make sense...

What I still don't understand is why doesn't this work

if (String.....)
->  item2=Size(DeviceInputs)
    -> item = Size(DeviceList)
          -> IsDigital = true
                - > (Shape) BlueOutline

I see the blue outline so I know it's getting executed... But the variable doesn't get updated on a different Chain under a different panel? It gets updated under a different chain under the same panel... But not a different sub panel.

Now if I add the "if false"

if (String.....)
->  item2=Size(DeviceInputs)
    -> item = Size(DeviceList)
          -> IsDigital = true
                - > [Shape] BlueOutline
                -> if (false)
                     -> [text] untitled

Then the variable gets updated and is accessable under the subpanel like I want it to be? Why is that??

Thanks for all the help so far.

Jim

[Opus4]

Most of this probably comes down to execution priority, or some such term. My guess would be that when you remove the text widget, the actual execution order of the UI chains gets changed, so when it checks IsDigital in your 2nd image (location #4), it hasn't yet been set to true when the loop leads only to a shape widget -- that is what you might be seeing if you go step by step in the debugger.

I like to have my UI loops lead up to something, instead of just ending, when possible. In your code, does the section of code that leads up to setting "IsDigital=true" do other calculations/settings? You may be able move that entire loop to be the parent UI tree for the EPGCell Item widget. You would probably have to place it under a panel so that you can add the Attribute widget(s) that you use. The code would be structured so that when it finishes doing all it needs to do in the loops, it continues on to the EPGCell Item widget, where all the stuff you just calculated & stored in variables would be used. But, you still can't leave sections of code in the loop dangling w/o leading to another widget. All roads must eventually lead to the EPGCell Item widget.

(If this were for an OptionsMenu, I would just place that initialization code in a BeforeMenuLoad hook so that it gets executed before the OptionsMenu starts displaying.)

- Andy

[nielm]

I believe text widgets have the highest priority -- i the action changes leading to text widgets will get executed before action chains leading to shapes... This may be why you are seeing odd behaviour, and why it looks better when there is a text widget in /at the end of the loop.

(and also why I used a text widget child as part of my If (False))

[Narflex]

When using the Tracer also look at the type of operation. When you see something multiple times its maybe because the Widget was encountered for various reasons (i.e. establishing layout, evaluating dynamic data, rendering)

[jbuszkie]

Originally Posted by nielm

I believe text widgets have the highest priority -- i the action changes leading to text widgets will get executed before action chains leading to shapes... This may be why you are seeing odd behaviour, and why it looks better when there is a text widget in /at the end of the loop.

I thought that all the chains got ececuted in the order they exist? Is this not true?

(and also why I used a text widget child as part of my If (False))

That's what I ended up doing and it seems to be working so far... Thanks!

[Opus4]

Originally Posted by jbuszkie

I thought that all the chains got ececuted in the order they exist? Is this not true?

Yes & no... it is pretty much true for Process chains, but obviously UI chains play by some different rules (see Jeff's post above). Deciding which UI elements get shown is an earlier phase process, so your text widget wasn't shown because IsDigital never had a chance to get set to true at the point when SageTV was evaluating which widgets were to be displayed. While Shapes do get shown on the screen, they are really a hybrid type widget -- think of it as an action that happens to get displayed on the screen.

- Andy