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

[bug][API][character sheets] If a user clears out a sheet field by highlighting it and pressing delete, it displays a zero, but stores an empty string.

1490349664
Chris D.
Pro
Sheet Author
API Scripter
Compendium Curator
I had a fun time chasing down a bug in my sheet today where the campaign API kept crashing.  Many of the fields on my character sheet are numeric, and many default to zero.  One of my players wanting to reset back to zero, selected the field and hit delete (as opposed to typing in a zero) I don't think that this is outrageous that he would innocently do this, and I think that doing this ought not break things. When he did this, the sheet, noting that it was a numeric field, DISPLAYED a zero, but what was stored in the database was an empty string. Some time later he pressed a button that is supposed to add up a few numbers and store the result. The API thread, read the empty string, tried to add some integers to it, and on the write event crashed with an error that it was trying to write NaN to a numeric field. I just want to emphasis this, that when a character is created, a zero is displayed and stored. When the user deletes a value, a zero is displayed, but an empty string gets stored. Then later on the API thread dies. I have upgraded this particular section of my code to make sure I have a number in all those fields, but  It would be very nice  if, when a user blanks out a numeric field, it not only displayed the default value, but it also stored the default value. 
1490351602
Jakob
Sheet Author
API Scripter
The behaviour between sheet/sheet workers/API with regards to defaults and empty strings is really confusing. On the sheet, any field whose corresponding attribute is an empty string will display the default value. When the sheet worker looks for the value of the field via getAttrs(), it will often split out the actual value of the attribute , namely an empty string. Since sheet workers cannot delete attributes, resetting a field to default by emptying it sounds reasonable, but it actually produces this weird behaviour. And finally, in the API, you have two ways of getting the attribute value: findObjs() and getAttrByName(). The former will find the empty string; I don't know what the latter does, since I never use it, but it is supposed to respect defaults as well. Does it return an empty string like sheet workers or (at this point) findObjs(), or does it give the default value (like the display on the sheet itself)? I think this is not just a problem for numeric fields: deleting the content should do one of two things, for consistency: 1) delete the attribute object, or 2) keep the attribute object, and set its value to the field default Since attributes with empty values may be desirable for some applications and 1) generally seems bad for compatibility with existing sheets, maybe 2) is the better choice.
1490359932

Edited 1490359980
Chris D.
Pro
Sheet Author
API Scripter
Compendium Curator
I don't know what getAttrByName() would do in this case, since in this case I am using findObjs().  Specifically, I am using findObjs(), testing to see if I found it. If so parseInt() and use the value to calculate the new value, if not create it, then in ether case write the new current value. My fix was to add a test to the result of parseInt() to see if it isNaN() before using the value.  However I susspect that I ought to go through all my code and add similer tests dozens of other places. 
1491429348
Gid
Roll20 Team
Speaking with the other Devs regarding this issue, this problem stems from browser fickleness with how they handle input fields. Our best recommendation is to code around this, like you mentioned earlier; parsing the value so you don't run into NaN results. 
1491476052
Chris D.
Pro
Sheet Author
API Scripter
Compendium Curator
Rather than having all users code around this behavior, it strikes me that if it is at all possible, it would be worth it to have the system code around it instead.  IE: if the system can somehow test that it is writing a null value for a numeric only field, substitute a zero value instead.  Or better yet, when the system is writing a null value into a numeric only field, take the trouble to find out what the default value for that field is (which might require jumping through a whole lot of hoops), and write that value instead. but the point is that once it was done once at the system level, the issue goes away. Rather than having to be coded around thousands of times at the application level.