> Hmmm. My PolyClock gadget's working fine for me since I implemented > the workaround (see below). In what browser are you having trouble, > might I ask?
Sorry for worrying you on this. I tried again and it was NoScript extension that has blocked JS from your gadget. > This isn't my experience, with a number of other gadgets. A non-blank > default value seems to suppress the extra hash parameter that's > causing all the trouble. Can you post a counterexample? It might be > helpful in getting to the bottom of this. When I had set a non-blank value as default, prefs object was returning me it even if I saved another value as pref. A blank default or no default value at all resolved to blank even if some other value was saved too. The thing here, I think, is that prefs handler considers only the last occurrence of the preference field name in url. As that, Gmail's container always adds a default value after the true value in url, e.g, &up_mypref=RealPrefValue#up_mypref=DefaultValue& (non-blank value) &up_mypref=RealPrefValue#up_mypref=& (no default value or a blank one) so you never get the real value user has set. The fix seems to be simply handling correctly this two values in url or removing the default one when another is provided. > That's what I ended up doing with PolyClock. Here's a function to do > so, if you need one: > Let us know how you do, Nice one. I made a little different version of this. I match the following pattern: &up_mypref=([^&#]*)#up_mypref Rafael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
