Help with Studio properties

[Tiki]

I am struggling with an issue in Studio that seems to be a timing problem with setting/getting a property. The attached picture shows a snippet of Studio code that executes in the before menu load hook.

Notice at the end of the code snippet I have a DebugLog statement that prints if ScreenLocked is not equal to true. Quite often this will fire and print the following to the log:

"***TIKI: Unlocked [false]{true}"

Of course when this happens, I don't get the desired results (In this instance it should be locked (true)).

How can this happen? Is the writing of the property file asyncronous? Is it cached for later? If it's cached, shouldn't the reading of the property be looking at the cached version?

The property "tiki/lock_videos" gets set in a separate configuration screen. Sometimes if I wait a long time between when I set the value in the configuration screen and when I enter the video browser screen it will work correctly. Or if I exit and re-enter the video browser screen it will work correctly.

If anyone can explain what is going on, please let me know. Or, if anyone has a better suggestion of how I should be doing this to ensure that the value I am using is "fresh" let me know too.

[GKusnick]

First of all, property values are stored in the file as text and returned from GetProperty as Java Strings. If you want a boolean-valued property, it's up to you to convert the resulting String to a boolean (using, for instance, java_lang_Boolean_parseBoolean).

In the same vein, note that GetProperty("someprop", true) is equivalent to GetProperty("someprop", "true"). In other words, the second argument is converted to a String before it's passed in to GetProperty (and likewise for SetProperty).

The other thing that strikes me as odd is the fact that you're doing AddStaticContext in a BeforeMenuLoad hook. AddStaticContext is meant for passing values from one menu to another, so typically you would call it just before linking to a Menu widget. If you want a permanent global variable, use AddGlobalContext. If you want a variable whose scope is limited to the current menu, use an Attribute widget.

Finally, just as a stylistic note, it's a bit weird (in my opinion) to test a boolean using "If bool == true". Just say "If bool"; it means exactly the same thing, and it's how booleans are meant to be used.

[Tiki]

Originally Posted by GKusnick

First of all, property values are stored in the file as text and returned from GetProperty as Java Strings. If you want a boolean-valued property, it's up to you to convert the resulting String to a boolean (using, for instance, java_lang_Boolean_parseBoolean).

Good point. I haven't done much Studio programming in a while and I forgot that very important point. I'll clean that bit up and see if it fixes my problem.

Originally Posted by GKusnick

In the same vein, note that GetProperty("someprop", true) is equivalent to GetProperty("someprop", "true"). In other words, the second argument is converted to a String before it's passed in to GetProperty (and likewise for SetProperty).

Right. Got it.

Originally Posted by GKusnick

The other thing that strikes me as odd is the fact that you're doing AddStaticContext in a BeforeMenuLoad hook. AddStaticContext is meant for passing values from one menu to another, so typically you would call it just before linking to a Menu widget. If you want a permanent global variable, use AddGlobalContext. If you want a variable whose scope is limited to the current menu, use an Attribute widget.

Yeah, I started out that way, but when things didn't work as expected, I tried experimenting a little with AddStatic and AddGlobal. I should have cleaned that part up before I posted.

Originally Posted by GKusnick

Finally, just as a stylistic note, it's a bit weird (in my opinion) to test a boolean using "If bool == true". Just say "If bool"; it means exactly the same thing, and it's how booleans are meant to be used.

Again, when things don't work the way I expect, I tend to try making the code more explicit to see if it makes a difference.

Thanks for the pointers, I will try cleaning things up and see if it makes a difference. I'm going to have to take a closer look at my sloppy code to see why it works at all - most of the time it does work as intended even though as you pointed out, true should never evaluate to "true" and false should never be "false".

[GKusnick]

Originally Posted by Tiki

true should never evaluate to "true" and false should never be "false".

Well, the widget interpreter does do some implicit conversions that Java doesn't do. In fact if you enter "true" == true into Expression Evaluator, it comes back true. So I'm not sure what to suggest other than to put in some more DebugLog calls to make sure your variables and properties contain what you think they do.

[Tiki]

Originally Posted by GKusnick

Well, the widget interpreter does do some implicit conversions that Java doesn't do. In fact if you enter "true" == true into Expression Evaluator, it comes back true. So I'm not sure what to suggest other than to put in some more DebugLog calls to make sure your variables and properties contain what you think they do.

Thanks for the push in the right direction Greg. I got it working.
I changed the AddStaticContext call to an attribute declaration. I also explicitly cast the return from GetProperty() as a Bool as you suggested.

The one tricky thing was that it would not work at all if the attribute was declared immediately below the BeforeMenuStarted Hook. I had to move it up a level so that the attribute was defined at the menu level (Immediately below the Browser-Videos Menu Item) otherwise it appeared as "Null". I guess it makes more sense to declare the attribute at the menu level anyway, but I was under the impression that an attribute widget could be placed anywhere and its scope would simply be limited to the branches of widget code that had the same parent widget as the attribute. At least that is how I interpret what is written in the studio manual.

[Opus4]

Originally Posted by Tiki

The one tricky thing was that it would not work at all if the attribute was declared immediately below the BeforeMenuStarted Hook. I had to move it up a level so that the attribute was defined at the menu level (Immediately below the Browser-Videos Menu Item) otherwise it appeared as "Null".

How did you get an attribute widget added as a child of the hook anyway? That isn't a legal placement for that widget type.

If you want the variable accessible from other parts of that menu, you need to place the attribute widget at the menu level. If it isn't going to be used anywhere other than in that section of code in the BeforeMenuLoad hook, then you don't even really need to define it as an attribute anywhere - it isn't considered the cleanest form of coding, but an automatic variable will work for a short section like that.

- Andy

[Tiki]

Originally Posted by Opus4

How did you get an attribute widget added as a child of the hook anyway? That isn't a legal placement for that widget type.

Strange, Studio allowed me to do it before, but now when I tried to do it again, it doesn't let me (cursor changes to the "can't do" red circle with a slash through it)...

Wait, now I know how I did it - I had a very similar attribute declared somewhere else and I copied and pasted it, then edited it. I just tried again and I see that Studio allows this. So apparently Studio checks when creating a new widget by dragging from the toolbar, but there is no check when pasting a copied widget.

[Opus4]

Originally Posted by Tiki

Wait, now I know how I did it - I had a very similar attribute declared somewhere else and I copied and pasted it, then edited it. I just tried again and I see that Studio allows this. So apparently Studio checks when creating a new widget by dragging from the toolbar, but there is no check when pasting a copied widget.

I tried that before I posted earlier & that didn't work either, so it appears that I'm using a more recent version of Studio & that has already been fixed.

- Andy