onValueChanged for preferences checkbox

[rule of three]

I want to activate a fonction if a particular checkbox is check in the preferences window.

I can handle manually but how can I use a sort of onValueChanged ? How to find the name of this box ?

Something like that :

PreferenceManager.onValueChanged("interface_myoption");

?

[Moon Wizard]

Typically, the change notification would need to be built into the option object by the people who developed it. I think PreferenceManager is built by the foundation ruleset team, so I'm not familiar with its usage.

The other option is to add an onUpdate handler for the database node where this data is stored in the campaign database. Again, this is specific to the PreferenceManager implementation.

In the 4E v2 ruleset which is soon to be release, I have a OptionsManager.registerCallback function where you can specify which option you want to watch, and which function to call when it changes. I would dig around in the ruleset you are using to see what PreferenceManager offers.

Cheers,
JPG

[rule of three]

Thanks. I'm working with the fundation ruleset.
In fact, it was the method I've begin to implement. Node update can be a solution.
Without them, my problem is that I don't know how to call my "onUpdate" function outside of the refeences.lua scrip itself.

I've try to use the console with print(getName()) or print(getWindows()...), but I think I'm still lost with this kind of auto-created windowclass.

So, if I had to resume that to ONE question, it will be "how to call the function I've created for a specific checkbox ?"

It's not a very important thing, it's just that it will be more clean if there is not delay between the activation of an option (checkbox check) and the effects.

[Foen]

I think the foundation ruleset has some kind of callback/observer mechanism - take a look at the code for the closebox in the foundation ruleset for this. The base ruleset that I use as an alternative to foundation doesn't have that functionality, so preference changes only take effect once the target object has been closed and reopened. I chose that method as:

Generally preferences don't change frequently, so the added responsiveness isn't needed
I presumed that the need to maintain callback lists and trap the preference changes was a runtime overhead
The code isn't trivial, and with the first two items above I didn't think it was a feature which demanded the effort

Sorry I can't be of more help, but I'm not familiar enough with the foundation ruleset to say much more.

Foen

[rule of three]

Thanks. I have create my onUpdate function and use it but it creates strange and non-euclidian effects on my database.

I will make a simple update : I will write "make sure to make a /save et /reload to active this option !" :D