2016-05-09, 04:56
(2016-05-09, 03:40)mikesilvo164 Wrote:(2016-05-07, 16:40)BobCratchett Wrote:I didn't think it would. If you want to take a look at the code used, it is here. If you prefer to test it out for yourself and let me know if it was a dumb idea or just poorly coded.(2016-05-07, 07:47)mikesilvo164 Wrote: The issue is those saying there menu reset cause of the update. I do not see how that is possible because even when you agree to reset it still requires a second confirmation from the user to perform it. This doesn't take into account people who do not wait for the update to finish and I have no idea if that would even trigger a menu reset by the skinshortcuts script.
For the record, it wouldn't. A menu reset is the deleting of the .DATA.xml and .properties file from userdata (wiki)/addon_data/script.skinshortcuts - there's no way a skin update could cause this, unless the new version of the skin calls the scripts inbuilt reset function (which is what I presume this skin does but, as Mike said, the script will then ask for confirmation from the user before deleting these files.)
Maybe I'm missing it, but has no-one captured a debug log yet...?
Add
to the latest Jarvis skin settings.xml file.Code:<setting id="Enable.AdvancedWidgets" type="bool">true</setting>
I'm not in a position to test at the moment (only up at this godforsaken hour to head to the airport), but from a quick look your code looks fine, and combine it with this (bearing in mind you're not disabling the warning, and therefore the script won't proceed without getting the user consent) I'm struggling to see how what you've done could trigger a menu reset without the user being prompted twice first.