populateListOptions for repeating sections in sheetworker

Helloes I am working on a custom character sheet for my homebrewed d&d 5e and hit a bit of an obstacle. I want to have dynamically filled dropdowns available for my attacks (for ammo types) and spells (for spell slots and other spell resources). As much as this would not really be an issue for ammo types (as there are like 4 main ones - arrows, crossbow bolts, etc.), it is for spells - as each spell can have really different dropdowns. I am using populateListOptions, but can't get it to work for repeating sections. Is it at all possible? I keep getting Character Sheet populateListOptions Error: select/data-list element not found. error whenever I try something other than putting an existing html class name. I've scoured the forums in search of a solution, didn't really find anything that solves the problem. My html wizardry is sadly at toddler level, so I don't know how to tackle it. I'd appreciate any help!

You're not getting much help because I don't think may people know about populateListOptions, never mind use it. I've never used it, but I vaguely remember a problem being described with it in repeating sections. We'll have to wait to see if someone can verify that.

My friend Ulti hit the same issue about one year ago <a href="https://app.roll20.net/forum/post/11900172/dynamically-created-options-in-repeated-sections" rel="nofollow">https://app.roll20.net/forum/post/11900172/dynamically-created-options-in-repeated-sections</a> Basically, since there are multiple rows with the same list of options, but you cannot set the various selected values independently, you end up resetting all values to the first option each time you open the sheet.

Hello Yeah, I'm aware of the limits, I wanted to know if there's some sort of a workaround. I've decided to just create a less-ideal, but still rather elegant solution of just creating a hyperling-like button that shows the dropdown for given repeating field only to change it. This is more than enough for my needs anyway - and more performant too, actually, since no need to refresh the dropdowns for all fields. Anyway, thanks for the answers.

Hi Well we’re hitting all sorts of limitations of half-baked features that will stay as they are or new bugs introduced with the enhancements to Jumpgate even in legacy games, and are reporting to Roll20 support (last one I reported was with screwed up eventInfo object for current/max attributes), but since the Roll20 developers are focused on the 5e24 sheet disaster, Jumpgate and Beacon, I don’t expect answers on legacy stuff for the months or even years to come, and I’m just learning to live with workarounds :)

It is possible to target populateListOptions to specific repeating rows. However, it requires some setup. Here's what you'll need: Replace the default add button with your own custom action button that will call a function that will create the repeating row Have an attribute in the repeating section that will store the original row ID (not lowercased). This can be a hidden attribute. Have your addRow function store the original row ID in the row_id attribute of the repeating section Now, we have the row_id with it's original casing available to get from our sheet data. From here, you just use populateListOptions as normal, but you add a selector for [data-reprowid=casedID] &nbsp;to the elemSelector property. e.g.: const trueID = attributes[`repeating_test_${rowID}_row_id`]; populateListOptions({ elemSelector:`[data-reprowid=${trueID}] .fill-target`, optionsArray }); This will then select only that row's version of the select. There is one caveat with this though; if you try to set the select on the specific row in the same callstack that you are creating the row in (e.g. when the user clicks on the add button), populateListOptions will not be able to find the row because it hasn't actually been added to the DOM yet. Nesting populateListOptions within the callback of a setAttrs causes a race condition where it will unreliably find the row depending on the speed at which individual functions finish. This is relatively easy to workaround by simply having the population of the list items occur in response to some other user caused change in the sheet.

Ohh, like that! I tried accessing data-reprowid somehow but failed and now I see I just should've done it the other way around.&nbsp; My rows are added programmicaly anyway and the add/delete buttons are removed completely so I have most of the work done already for your solution. I'll try it once I'm by my PC, many thanks! On another note, would having somewhere in the vicinity of 100 dropdowns per character sheet performance heavy? Since that's the count I'll expect from my sheet. I will probably know soon enough when I test it out.&nbsp; Anyway, thanks a lot again&nbsp;

Oh it's working wonders. I do have the race condition, so will have to think about how to solve it, but this works. You are a national treasure, mr Scott. Of uh, whatever country you're from. If it's USA, keep an eye on Nicolas Cage. Cheers!

Wow, that’s a good one. I’m too lazy to implement it, but that is definitely a keeper Thanks Scott C. :)

Thanks all! Grzegorz S. said: Oh it's working wonders. I do have the race condition, so will have to think about how to solve it, but this works. There are two ways I've thought of to get around the race condition: First is to have a listener triggered by one of the changes you make programmatically and that listener is what does the populating. I haven't really investigated the timing differences between calling something in the callback of setAttrs and calling that thing in a listener triggered by the effect of a setAttrs so I don't know if the delay here would be enough to avoid the condition. The other is to await a "fake" message via startRoll before doing the populate. This probably has the best chance of working, but has the downside that you'd be polluting the chat history. You can at least prevent it from being noticeable to players by prefixing the message with an exclamation mark to mark it as an API message.

I wish there was an on dropdown event we could use to populate the options and that the populate function would not set the value of the select tag.&nbsp;