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

New repeating entry at the top

Hi, I'm hoping to have a repeater where the newest entry is at the top of the list, not the bottom. The Add and Modify buttons should be at the top too in this repeater. This is so players can create log entries with the newest at the top for easy finding. There's going to be a LOT of entries. Hundreds. Also there's going to be a sheetworker doing math on the most recent as it relates to the one just below it. Is there a way to make the sheetworker not do its calculations till a "Process" button is pushed? I ask because any changes made to earlier entries are going to need to be propagated back up to the top. It's going to be super-slow if it re-calculates every entry if a change is made earlier than the most recent entry.
1586693115
Jakob
Sheet Author
API Scripter
FYI: a repeating section with hundreds of entries, if there are a lot of fields per field, is going to make your sheet pretty slow. Be warned. What you can do here is use CSS to change the order of things within the section, something like .repcontainer[data-groupname="repeating_foo"] { display: flex; flex-flow: column-reverse; } This will make the entries flow from bottom to top, so new entries should appear a the top. You can probably also do it using CSS grid, but I'm not sure how. And for the outer container, you can use either grid or flex and the order  property to put the .repcontrol div for this section before the .repcontainer div, so that the Add and Modify buttons end up at the top. Is there a way to make the sheetworker not do its calculations till a "Process" button is pushed? I ask because any changes made to earlier entries are going to need to be propagated back up to the top. It's going to be super-slow if it re-calculates every entry if a change is made earlier than the most recent entry. Yup, just don't trigger your calculations on a change of the attribute, just listen until the button is clicked using on("clicked:<buttonName>", ...). This means that you should not rely on cascading workers, but compute everything in one go, which will be orders of magnitude faster than cascading for such a large section. By the way, your algorithm sounds potentially quadratic, so you better make sure it's written efficiently... make sure to only use a single getSectionIds(), getAttrs, and setAttrs call each in your function and it should work best.
1586695098
GiGs
Pro
Sheet Author
API Scripter
Also, do the ones below need to be recalculated every time a new entry is calculated? 
Thanks very much for all the advice. :) The entries are for logs in a police logbook. This means that previous entries should theoretically not ever be adjusted, but gamers be gamers... mistakes are going to happen. In the event that a player needs to go back into an earlier entry and make an adjustment that affects the math, we're going to have to recalculate the whole dang thing. But only when we want- hence the button Jakob mentioned above. Thanks for that. Very helpful. I'll see about making this work. Oh hey, speaking of arranging repeaters, does CSS flow allow one to alphabetize a list of repeaters too? (different list)
Will the "Add" and "Modify" buttons be at the top or the bottom?