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

Unhelpful discrepancy between getSectionIDs & findObjs

1457029018
Lucian
Pro
API Scripter
getSectionIDs as called in a sheet worker script returns a set of lowercased ids for the rows in a repeating section. If you copy and paste these ids into the appropriate attribute expression in the chat window or a macro, they return you the appropriate attribute value, and of course they work just fine within the context of a sheet worker script. Sadly, if you try and use these values via the API (I tried storing one in an attribute for later use, since I wanted it output by one of the character sheet rolls), you discover that findObjs is case-sensitive - it won't find the attribute with the lowercased id, it needs the original casing. There's no way to reconstruct this, short of getting all the attributes for that section and doing a manual case-insensitive match across them.  Now I get that I'm probably pushing the boundaries of what was intended here, but the difference in behaviour seems perverse and unnecessary; why can't getSectionIDs return the proper IDs rather than lowercasing them?
1457030355
Lucian
Pro
API Scripter
Ok, so I've realised that I can supply {caseInsensitive:true} to findObjs to work round this. Still, it's kind of worrying that something that's effectively a primary key has different casing in different parts of the system - not sure if this could result in unwanted duplicates?
1457039576

Edited 1457039909
Chris D.
Pro
Sheet Author
API Scripter
Compendium Curator
Apparently for some reason some of the keys get cast to lower case before being stored in some table. This was not a problem for a very long time, until they recently made these values visible to us.  Apparently the developers all work in strictly lower case, and did not realize that there even was a problem with mixed cases until some of us that use mixed cases in our code started having problems. One publicly commented shortly after sheet-workers were introduced that all of us ought to simply work strictly in lowercase as well from now on. Unfortunately, that was many months after I started my development and I don't really feel like going back and changing everything (which would break all the characters in my campaign).  So basically it is just a SNAFU. You MAY use mixed cases, and you will have no problems doing --- just about --- everything. But apparently for easiest results, stop using mixed case.