Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Sheet workers are now both case sensitive, and case-insensitive. (probably a bug)

1627192684

Edited 1627193702
GiGs
Pro
Sheet Author
API Scripter
I had noticed something weird about case sensitivity in sheet workers and tonight tested it properly, thanks to a question over in the API forum. I'm reposting here, because its more relevant to character sheet authors. In the past, sheet workers completely ignored case in attribute names. The on() line needed to be in lower case regardless of the attribute defined in html, but in getAttrs and value statements, it could be anything. But sheet workers are now both case sensitive, and case-insensitive. Honestly, I don't know if I've tested this before, but I think it's new behaviour. Testing So, when doing a getAttrs, the case does not need to match the case defined in the html. Let's say you define the str attribute with <input type="number" name="attr_str" value="5" /> Note that the case here is lower case. Now, in getAttrs you can use either of getAttrs(["str", getAttrs(["STR", Both work. (As would any case, like sTr , or STr ). But whichever case you use, when later grabbing the attribute, you must use the same case . So if you use getAttrs(["STR", you must grab it with values.STR It will fail if you try to use values.str even though that's the case actually defined in the html. This looks very much like a bug to me, but even if it isn't, people should be aware of it, because it could be a very frustrating problem to track down if you accidentally use differing cases in your code because you're used to it not mattering.
1627194046
GiGs
Pro
Sheet Author
API Scripter
Note that if this is indeed new behaviour, I imagine it's a result of roll20 fixing bugs, even though it now looks like a bug. Because getAttrs creates a javascript object, and variable names in roll20 are case-sensitive, they may have corrected previous behaviour to match proper JS behaviour. But the side effect of that is just weird (getAttrs 'fixes' the case of attributes, for later use). And of course, it's possible this isn't new behaviour and I just hadnt noticed it before.
1627196422

Edited 1627196444
vÍnce
Pro
Sheet Author
I have an API script that suddenly(at least I did not notice before...) BlindChecksPF started failing to pull attribute data for some sheet attributes.  Upon further investigation, I found that the HeroLab importer for the PF Community sheet changes many of the default sheet attributes to lowercase.  This never seemed to matter for macros and sheet calcs...  This has definitely broke the BlindChecksPF script (I've made a temp fix by including both versions of the necessary sheet attributes to cover the default as well as characters imported from HeroLab).  Now I'm wondering if this change is adversely effecting sheet calcs for these imported characters as well...? ;-(
1627201032
GiGs
Pro
Sheet Author
API Scripter
I dont think it'll be affecting sheet calcs, because the case doesn't matter up until the getAttrs line. That line sets the case needed for the rest of the worker, and that will be set by workers not the script. The case of the attribute in the character sheet itself (which your script will be creating) doesn't seem to matter. Worth checking, but I think you'll be okay there.
1627207979

Edited 1627208211
Oosh
Sheet Author
API Scripter
Hmmmm.... the part where you're grabbing the value inside the callback function with: values.STR is not part of the sheetworker - that's standard JavaScript object syntax which is always case sensitive. So I don't think that could have changed - getAttrs is just assigning the object Key names from the user input. Whether or not getAttrs has always been insensitive I have no idea, as I've only just started on sheets. Maybe it would be better behaviour if getAttrs accepted upper or lower case, but gave the key names a .toLowerCase() before assigning them to the output object. Or maybe not? Some people might prefer to have camel case in their getAttrs objects.... who knows?
1627219141
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
I'm reasonably sure that you've always had to match the case used in getAttrs when accessing the values parameter. Now where we should test is if changing the case in the setAttrs key changes the case of the attribute that is updated/created, potentially duplicating attributes.
1627230076
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
And, something I just realized. setAttrs is definitely case sensitive because it has to be in order to properly set a repeating attribute as the row IDs are case sensitive (and even are for getAttrs) as noted in the code comments on the sheetworker wiki section : on ( "change:repeating_spells:spellname" , function (eventInfo) { //Do something here // eventInfo.sourceAttribute is the full name (including repeating ID) of the attribute // that originally triggered this event, // however the entire string will have been translated into lowercase and thus might not be // suitable for being fed directly // into getAttrs() or other uses without being devandalized first. });
1627234773

Edited 1627234947
Jiboux
Pro
Sheet Author
Compendium Curator
I had a lot of headaches with this in the sheet development I am in right now, and had come to the conclusion by trial and error that: - Sheetworker is now case insensitive (at least on the Sheetworker sandbox)... I have had cases where I had only the vandalized rowid, and the update was proceeding as it should. I see your point that the collection returned by getAttrs will have to be called with the same case as the initial getAttrs - eventinfo returns vandalized attributes, including rowid and names, but sheetworker is now able to do getAttrs and setAttrs with no case sensitivity - API, and SetWithworkers are somehow case sensitive for repeating section (i.e. a setwithworker with repeating_xxx_HighCaps was not triggering, on(change:repeating_xxx:highcaps), but the same with all low caps was triggering), and in general the API remains fully case sensitivie
1627235340
Andreas J.
Forum Champion
Sheet Author
Translator
So one more reason to lowercase every attribute, no matter if it's sheet html, sheetworkers, repeating section or API.
1627235960
Jiboux
Pro
Sheet Author
Compendium Curator
True, if you know it from start, and start from scratch... Working with a 1000+ attribute sheet that was started years ago without realizing this, that s another subject
1627243678
Andreas J.
Forum Champion
Sheet Author
Translator
Jiboux said: True, if you know it from start, and start from scratch... Working with a 1000+ attribute sheet that was started years ago without realizing this, that s another subject Oh yeah refactoring things is a pain, creating new stuff is much easier in many cases.
1627246429
GiGs
Pro
Sheet Author
API Scripter
Scott C. said: And, something I just realized. setAttrs is definitely case sensitive because it has to be in order to properly set a repeating attribute as the row IDs are case sensitive (and even are for getAttrs) as noted in the code comments on the sheetworker wiki section : on ( "change:repeating_spells:spellname" , function (eventInfo) { //Do something here // eventInfo.sourceAttribute is the full name (including repeating ID) of the attribute // that originally triggered this event, // however the entire string will have been translated into lowercase and thus might not be // suitable for being fed directly // into getAttrs() or other uses without being devandalized first. }); This may be true now, but definitely always wasnt the case. I've used setAttrs commands with case of attributes that did not match the case set in the html, and it worked fine. Repeating sections are different, because case of row ids is case-sensitive - but I dont think I ever set a repeating section attribute without first getting the id using getAectionIDs, so the case would always be correct there.
1627326983
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
So, something else that I just discovered. getSectionIDs is now returning vandalized repeating IDs, so we don't have any way to devandalize the row IDs currently.