Set datalist options with sheetworker

Hello, Is it possible with the js commands available with the sheetworker to do something like the link below, i.e. set dynamically the list of options of a datalist by a js sheetworker. <a href="https://www.plus2net.com/javascript_tutorial/datalist.php" rel="nofollow">https://www.plus2net.com/javascript_tutorial/datalist.php</a> Objective is that I am making a levelling up button for my sheet that will create all the abilities available at the next level. When there is no choice to be made, it is pretty simple, create the repeating item, and fill it with appropriate data. But there are options to chose from, and currently I am just putting a list of those options in a comment attribute, but it would be a lot cooler if they could have a dropdown list with exactly what they need...

Unfortunately, it is not possible (to my knowledge). I think the best way to achieve this would be to hide all the possible select elements and show the one a player should interact with. Rol20 CSS Wizardry &nbsp;has an example how to do multiple hide/show elements based on radio inputs and CSS providing the hide/show code based on the radio value.&nbsp;

Thanks.- a lot for the answer

Another option would be to use CRP to dynamically create a roll query that would be sent to the user. It's about as close to dynamic selects as we can come, although it's more like a popup.

Interesting, but knowing that there may be several lines called at the same time, that may create a popup overload ;)

Yep, it's not an ideal solution for all issues.

While you cant do exactly what you need, you might be able to fake it. You can create a different pre-built datalist for each level, then switch out which one is active based on some criteria (like level). If the list is always the same for a given level, or class + level, or whatever, it can be done - it just needs a lot of prebuilt lists to be created.

You could also utilize the newish R20 Jquery implementation ($20) to show/hide selected options from a given datalist based on what you need. You'd do this by adding a class to those options that should be hidden and giving that class&nbsp; display:none &nbsp;in your CSS.

That sounds like a genuinely useful use for R20.

Yep! I've used it in a few situations so far. I haven't done it with a datalist setup yet, but I imagine it'd work the same. Here's some example code: HTML &lt;select name="attr_my_select"&gt; &lt;option class='conditional-option' value="1"&gt;Option 1&lt;/option&gt; &lt;option class='conditional-option' value="2"&gt;Option 2&lt;/option&gt; &lt;option class='conditional-option' value="3"&gt;Option 3&lt;/option&gt; &lt;option class='conditional-option' value="4"&gt;Option 4&lt;/option&gt; &lt;/select&gt; &lt;button type="action" name="act_toggle-1"&gt;Toggle Option 1&lt;/button&gt; &lt;button type="action" name="act_toggle-2"&gt;Toggle Option 2&lt;/button&gt; &lt;button type="action" name="act_toggle-3"&gt;Toggle Option 3&lt;/button&gt; &lt;button type="action" name="act_toggle-4"&gt;Toggle Option 4&lt;/button&gt; &lt;button type="action" name="act_reset-all"&gt;Reset all&lt;/button&gt; &lt;script type="text/worker"&gt; const toggles = [1,2,3,4]; toggles.forEach((toggle)=&gt;{ on(`clicked:toggle-${toggle}`,()=&gt;{ $20(`option[value="${toggle}"]`).toggleClass('disableOption'); }); }); on('clicked:reset-all',()=&gt;{ $20('.conditional-option').removeClass('disableOption'); }); &lt;/script&gt; CSS .disableOption{ display:none; }

That looks nice, but the main reason I havent explored R20 yet (apart from limited time) was the revelation that actions don't persist through closing a sheet, or relaunching a campaign. Am I misunderstanding that? If I've understood it properly, it seems to make a lot of potential uses not worth doing, because any button clicks would be undone on next sheet opening (or next person opening that sheet). But the idea in this thread, of this datalist or select being updated according to current level, would work properly regardless of whether sheet has been closed. That was the reasoning behind saying it was genuinely useful. PS: sorry to OP for this potential derail.

Yep, I don't want to hijack the thread too much, but for most use cases of this, you do need to run an on(opened) &nbsp;event to setup the styling properly for uses where the styling should persist. The solution to that is to functionalize your manipulation of the classes so that you can call the same function from the change/click listener and the open listener. Takes a little more setup, but the benefit is that it makes the CSS MUCH easier to write, and I think read, because you don't have to do long complicated chains of selectors, siblings, and children to target the areas you want to. It also makes the html simpler because you don't need to have a checkbox/radio in a specific place on the sheet to manipulate the display state of a given section. The desync between multiple people viewing the sheet is both a problem and a benefit though, as it lets you create views for individual users of the sheet at the same time. Of course, depending on the sheet's purpose, that can also be a problem. EDIT: Edited with some additional details on dealing with persistence of style.

Thanks a lot for the suggestions of prefilled datalists but I am working on it based on compendium integration, so I am trying to move away from hardcoded data in the HTML... Not only would I need something like 15 classes x 4 lists of approx 10 items (so 600 lines of code just for this), but that means I lose the scaleability I am trying to get to of basing the stuff on the data that comes from the compendium...

It sounds like what you want is to build a character mancer. This is the sort of thing that the character mancer is meant for.

Scott C. said: Yep! I've used it in a few situations so far. I haven't done it with a datalist setup yet, but I imagine it'd work the same. Here's some example code: HTML &lt;select name="attr_my_select"&gt; &lt;option class='conditional-option' value="1"&gt;Option 1&lt;/option&gt; &lt;option class='conditional-option' value="2"&gt;Option 2&lt;/option&gt; &lt;option class='conditional-option' value="3"&gt;Option 3&lt;/option&gt; &lt;option class='conditional-option' value="4"&gt;Option 4&lt;/option&gt; &lt;/select&gt; &lt;button type="action" name="act_toggle-1"&gt;Toggle Option 1&lt;/button&gt; &lt;button type="action" name="act_toggle-2"&gt;Toggle Option 2&lt;/button&gt; &lt;button type="action" name="act_toggle-3"&gt;Toggle Option 3&lt;/button&gt; &lt;button type="action" name="act_toggle-4"&gt;Toggle Option 4&lt;/button&gt; &lt;button type="action" name="act_reset-all"&gt;Reset all&lt;/button&gt; &lt;script type="text/worker"&gt; const toggles = [1,2,3,4]; toggles.forEach((toggle)=&gt;{ on(`clicked:toggle-${toggle}`,()=&gt;{ $20(`option[value="${toggle}"]`).toggleClass('disableOption'); }); }); on('clicked:reset-all',()=&gt;{ $20('.conditional-option').removeClass('disableOption'); }); &lt;/script&gt; CSS .disableOption{ display:none; } Sadly it does not work with datalists. I have made a suggestion for allowing to use the actual disabled flag to show / hide datalist items <a href="https://app.roll20.net/forum/post/10709362/extend-roll20-jquery-to-allow-toggling-of-the-disabled-tag" rel="nofollow">https://app.roll20.net/forum/post/10709362/extend-roll20-jquery-to-allow-toggling-of-the-disabled-tag</a> In this post I have a link to a Jsfiddle that shows that it doesn't work:&nbsp;<a href="https://jsfiddle.net/gu8knrhw/" rel="nofollow">https://jsfiddle.net/gu8knrhw/</a>

Jiboux said: Thanks a lot for the suggestions of prefilled datalists but I am working on it based on compendium integration, so I am trying to move away from hardcoded data in the HTML... Not only would I need something like 15 classes x 4 lists of approx 10 items (so 600 lines of code just for this), but that means I lose the scaleability I am trying to get to of basing the stuff on the data that comes from the compendium... I know you said you wanted to avoid hardcoding but unfortnuately Roll20 is not that flexible. The best you can do is to write out all the lists and then use sheetworker code to switch between what list to use. If there are overlapping items in the list then your inner programmer will die due to duplication of code. If you have any votes you can give this suggestion a vote. It will trying and help to get a little more scalabilty, when there is an overlap of between different lists, by allowing the javascript to show/hide options in a datalist:&nbsp; <a href="https://app.roll20.net/forum/post/10709362/extend-roll20-jquery-to-allow-toggling-of-the-disabled-tag" rel="nofollow">https://app.roll20.net/forum/post/10709362/extend-roll20-jquery-to-allow-toggling-of-the-disabled-tag</a> With this it would be possible to hide all the options that are not relevant for your current situtation.

Scott C. said: It sounds like what you want is to build a character mancer. This is the sort of thing that the character mancer is meant for. Hey Scott C. Can sheet authors implement the charactermancer? I have seen no one do that so far, so I have no idea of how it works. Does it require a compendium or can it be done with just data available in javascript?

Yep, we can make them for our sheets, but the charactermancer code will not run if there is not a compendium active in the game.

Scott C. said: It sounds like what you want is to build a character mancer. This is the sort of thing that the character mancer is meant for. Yes... and no ;) I have a character sheet where with the approval of the publisher, we integrated some hardcoded databases that autofill some "technical data"... For example it could fill in that you have a certain ability, and the stat it is based upon... But you wouldn't get the description, so you can't play without the books. We are right now working on the compendium, and the sheet would remain compatible with both the hardcoded database (no description), and the compendium. Ideally at some stage, It is true that a charactermancer would be nice, but I have already the functionality that creates all the repitems... Just looking how I could improve it... But knowing I am currently working on the compendium, I don't want to increase even more the quantity of hardcoded stuff