Setting properties that are tested in an STVi

[michaeldjcox]

I wrote STVI for a plugin that calls GetProperty(prop, defvalue) to make choices about what to present to the user.

I noticed that currently - using setProperty and setServerProperty in the API from my server plugin both seem to set values in Sage.properties.

But the presence of my STVI in the client has led to the properties being recorded in the SageClient.properties with default values.

Is it possible to set those client properties from a server plugin?

Thanks in advance for any advice!

Michael

[PLUCKYHD]

SetServerProperty
And
GetServerProperty

Will always get and set properties on the server from any client or server.




Getproperty
And
SetProperty

Set and get client specific properties

[michaeldjcox]

Thanks for your help.

May be its because my client and server are on the same laptop.

Calling:

SageTV.api("SetProperty", new Object[] {property, value});

from my server plugin seems only to result in Sage.properties being set and not SageClient.properties.

And hence my STVi is ignoring the properties

Michael

[PLUCKYHD]

Originally Posted by michaeldjcox

Thanks for your help.

May be its because my client and server are on the same laptop.

Calling:

SageTV.api("SetProperty", new Object[] {property, value});

from my server plugin seems only to result in Sage.properties being set and not SageClient.properties.

And hence my STVi is ignoring the properties

Michael

Are you running in service mode?

[michaeldjcox]

I've changed my STVi to do GetServerProperty instead of GetProperty.

Seems to do the trick for now.

Michael

[michaeldjcox]

Originally Posted by PLUCKYHD

Are you running in service mode?

SageTV is running as a service.

Michael

[GKusnick]

What are you trying to accomplish here? If these are global settings that apply to all clients, then you should use Get/SetServerProperty to access them. If they're per-client UI option settings, then you should use Get/SetProperty, and your backend server code shouldn't be accessing them at all.

[tmiranda]

Slightly OT, but I have grown to really like the UserRecordAPI for storing data that needs to be shared among various UI instances.

100% agree that you should use SetProperty for instance specific values and SetServerProperty for values that are shared among all UI instances.

Another small gotch with properties, they are all Strings. In most cases the expression evaluator will convert them to the right type, but not all. Something like:

GetProperty("propertyname", defvalue) + 1

May result in "51" if the value of the property is "5". Multiplying by 1 will ensure conversion to an integer so you will often see things like this in Studio:

val = GetProperty("propname", defvalue)*1.0 + 1

[GKusnick]

Originally Posted by tmiranda

Multiplying by 1 will ensure conversion to an integer so you will often see things like this in Studio:

val = GetProperty("propname", defvalue)*1.0 + 1

Multiplying by 1 will indeed convert it to an integer, but multiplying by 1.0 will convert it to a float.

My attitude on such things is that if you want to convert a string to an integer, you should say so explicitly by calling parseInt. Relying on obscure multiplication tricks to do the conversion implicitly does not make your code easier to understand.

[tmiranda]

Originally Posted by GKusnick

My attitude on such things is that if you want to convert a string to an integer, you should say so explicitly by calling parseInt. Relying on obscure multiplication tricks to do the conversion implicitly does not make your code easier to understand.

Agreed. I pointed this out because it's in the default STV and when I first looked at it I was confused.

I'm also lazy and have sometimes not followed your good advice and simply multiplied by 1 to do the conversion.