Help setting 'max' value of an input based on another input

I am so bad at javascript, and seem to have real trouble searching these forums for similarly posed problems, so apologies if this is either really easy or impossible but been asked a million times before: How do I set a value's max to equal another value? I have tried < input name = "attr_vigor" class = "underlined vigor" value = "0" min = "0" max="@ {vigor|max}" type = "number" title = "@{vigor}" /> < input name = "attr_vigor_max" hidden = "true" type = "number" title = "@{vigor|max}" /> which doesn't work... vigor_max is calculated by a sheetworker, which just returns " attributes . vitality * ( 4 - attributes . wounds )" any help?

The html tags of min and max dont work in roll20 so its fine to omit those. It sounds like yourissue is with the sheet worker, so you'd be bettor off posting that.

The 'max' attribute on the <input> element is an HTML attribute - this has nothing whatsoever to do with Roll20, and will not calculate a value from Roll20 attributes. It also won't stop anyone typing larger numbers into an input. And finally, you can't set it programatically without DOM access, which Roll20 prohibits. You can stop invalid number inputs with a sheetworker. Something like this: const boundNumber = (value , min , max) => { [ value , min , max ] = [ value , min , max]. map (input => parseFloat (input)) ; if (! isNaN (value)) { value = (! isNaN (min)) ? Math . max (value , min) : value ; value = (! isNaN (max)) ? Math . min (value , max) : value ; } return value ; } on ( 'change:vigor' , () => { getAttrs([ 'vigor' , 'vigor_max' ] , (attributeValues) => { const boundValue = boundNumber (attributeValues.vigor , 0 , attributeValues.vigor_max) ; if ( boundValue != attributeValues.vigor) { setAttrs({ vigor : boundValue }) ; } }) ; }) ; I haven't touched a sheet in a long time, you might be able to get the vigor_max value from the event object to save a getAttrs call... but I think it only contains the value of whatever was changed (current or max). There's a lazy loose equality in there (!= instead of !==) which is generally frowned upon. But I'm feeling reckless.

Thanks! This seems to work :D Though when you say "l oose equality (!= instead of !==)" does it actually make a difference? I tried it with  !== too and it also seems to work. Is one or the other likely to cause unknown problems?

Seraaron said: Though when you say "l oose equality (!= instead of !==)" does it actually make a difference? I tried it with  !== too and it also seems to work. Is one or the other likely to cause unknown problems? If you do the loose equality, Javascript converts the types of the items be the same. This seems  like it's the better behavior as then we can easily do something like '0' == 0 . But , there are some weird edge cases where the conversion does not do what you'd expect and the comparisons are not transitive. Some examples the non transitive nature of the loose equality (adapted from Douglas Crockford) are: '' == '0' // false 0 == '' // true 0 == '0' // true false == 0          // true false == 'false' // false false == '0' // true false == undefined // false false == null // false null == undefined // true Those first three doing the string comparisons are what are most likely to trip you up with sheetworkers as all the data from the character sheet comes in as strings. Using strict equality ( !== and === ) requires us to explicitly convert our data to be the same type, but avoids the quagmire created by the loose equality's implicit type conversion.

Scott C. said:  Using strict equality ( !== and === ) requires us to explicitly convert our data to be the same type, but avoids the quagmire created by the loose equality's implicit type conversion. Sadly, this isn't something that vanilla Javascript can do competently... or even adequately :) parseInt() throws some results which make me feel queasy, but so does the unary operator.

It's better tp use the triple equality ===, not loose equality ==, specifically because it will cause an error if the data type is not what you're expecting. This forces you into building your code so that you always know the data type. Subtle errors can creep in if you let the wrong datatype through (which happens with loose equality), or type coercion that happens with loose equality can itself cause subtle errors. Honestly, for sheet worker purposes, it's probably not going to matter very often, so you should use whichever you are most comfortable with. But the advice is always to use strict equality (===).