Persistent Settings Update


Soon after I posted my persistent settings library, I received my first bug on it.  I’ll discuss the bug a bit, but first things first – the bug is fixed, and the links updated; if you previously downloaded the library, please go ahead and get the updated version.

Details:

The symptom of the bug was that the following two consecutive calls:

getPersistentSetting( "setting", firstCallback );
getPersistentSetting( "setting", secondCallback );

Would result in two calls on the ‘secondCallback’ function.  The failure itself made it clear to me where the error was; and the location of the error suggested the fix.  I’m afraid I don’t know enough about the intricacies of the javascript language to know exactly why it failed in the first place, though; perhaps one of my more knowledgable readers will chime in.

Here is the failing code:

window.setTimeout(function ()
{
    try
    {
        workItem.callback(returnValue);
    }
    catch (e)
    {
        persistentSettingLog("exception from callback: " + e.name + ": " + e.message);
    }
}, 0);

And here is the fixed version:

persistentSettingScheduleCallback(workItem.callback, returnValue);
function persistentSettingScheduleCallback(callback, returnValue)
{
    window.setTimeout(function ()
    {
        try
        {
            callback(returnValue);
        }
        catch (e)
        {
            persistentSettingLog("exception from callback: " + e.name + ": " + e.message);
        }
    }, 0);
}

Comments (7)

  1. In my earlier post , I talked about WPF in the Sidebar by using the IFRAME to host XBAPs. In this post,

  2. Steve Waring says:

    If you think re-entering your location into the weather gadget is a pain, try re-entering all your stock portfolio into a stock ticker gadget.

    The article on persistent variables is very interesting.

    However there are a couple of drawbacks.

    1. For existing gadgets, you will have to wait for someone to redevelop them to use persistent variables – or do it yourself.

    2. For some gadgets, some in the user community may prefer transient variables, whilst others might prefer persistent variables. It would be possible to cater for this using a persistent variable to hold the user’s preference, and then use transient or persistent variables within the gadget, but this is at the cost of more complexity and development and maintenance overhead.

    A far more elegant solution would be for a change to the gadget engine. When the spanner (settings) icon is displayed, display another icon below it that allows the choice of transient or persistent variables. Have the code for this functionality within the System.Gadget.Settings object. At a stroke any gadget can have persistent variables without any re-coding, and users have the choice.

    OK, a lot to ask, but it would be a great improvement to the gadget engine. Here is another one:

    Allow multiple profiles for gadgets displayed in the sidebar. If I am working offline on my laptop, it’s pointless having gadgets displayed that depend upon an internet connection. However local only gadgets, such as a CPU monitor are still useful. By allowing users to add gadget profiles, u(eg online, offline,etc) gadgets could be displayed to match a users current requirements. This only really becomes viable if the gadget engine offers persistent variables.

    Steve Waring

  3. Steve Waring says:

    Thinking about it some more, it would also be useful to have:

    System.Gadget.Settings.forcePersistence(variable, "persistent")

    and

    System.Gadget.Settings.forcePersistence(variable, "transitory")

    for those occasions where no matter a users preference a persistant variable is needed, or where there is no use for a persistent variable.