|
|
|
|
|
|
|
|
|
 Posted: Thu Oct 18, 2018 1:55 pm
|
|
|
|
|
|
|
|
|
|
|
Posted: Thu Oct 18, 2018 9:16 pm
 |
|
|
|
this got.. LONG >_>;;
Letsee, wanted to make the formula explaining post better [I used the most complex looking formula intentionally, but I think I can explaining it better] Removed part 3 breakdown and instead leading with a summary of what the code was designed to accomplish, then follow with the code bits that does it. [+done]
Also was thinking yesterday to put in a example of a section of the bewere spreadsheet and show what the automatic highlighting can look like. It's got some nice automatic formatting but a lot is manual, many columns are just to help keep track of which pose it which, it goes into some 40+ columns horizontally but 2/3 thirds are just room for bbcode tags. And most is left blank since most items don't have 8 poses with cuts. [+added to the sheet, don't have much text mentioning it atm, maybe later]
And was thinking to throw together a template that only makes indexes [+added]
Yeah, they can be a bit daunting.
Summary: paragraphs 1:3 are about why I've learned to do this stuff, 4:7 are about queries
I really went into formatting with sheets when Spinami came out. I helped out a bit with late-night sessions of manually assembling the daily wheel updates into blocks of links It was a slow process especially at the very beginning when Spinami first came out couldn't mouseover for item names, so was not just the assembling the items but also playing "which recolor is that based on 2 uniquely colored pixels" and "what's that bundle named". It sped up once mouseover was added, but was still a very laborious process.
I tracked down the file that was being downloaded when loading Spinami that contained all the name and link data, but it was buried. So I worked to learn if I could extract it using a spreadsheet, at first I would have to manually arrange the extracted data [sorted by release date] into a tidy link brick. But further efforts allowed both automating the layout and getting it to match the wheel order. Now getting a daily Spinami update is a two copy-paste operation: Copy raw data in, Copy processed data into a post. So in short: yay spreadsheets!!
After having brute-forced my way thru learning to do that, I started to think that the bewere project I had been considering of tracking what poses did what would be doable with spreadsheets to keep things organized and I took off on figuring that out next. Fast forward to now, I hadn't been doing much with trying to get more out of spreadsheets for some time, when I threw together the Lake Kindred: Origins KinApp sheet to track some data it got me poking into it again and I ended up inspired to challenge myself to developing some sheets, even without having a personal use for, and it's resulted in this. My benefit is mostly having picked up new tricks for projects I've been considering.
--
Queries are nice in that they don't affect the data, they're basically just copying lists [either exactly the same or filtered] that update when data in other sheets are updated
They're instrumental in the Spinami sheet to pull data based on keywords and edit out excess text/punctuation. However the bewere guide never had any queries, by going with a [list ] based format I avoided needing any carriage returns, and it works since the entries benefit from bullet points helping identify groups. The sample templates I made for items rely on carriage returns to break up the data, the queries in those sheets mostly remove excess carriage returns.
In some cases like the LinkBrick, the 10x30 output is hard coded to ensure rows of 10. For this the query is used to copy a list of link data, it looks identical to a column in the Data sheet but there is a key difference. The Data sheet has data in every iconlink cell, while the Query has data in the top cell and the list of iconlinks are dynamically generated below. Adding/deleting lines in the data doesn't add/delete rows in the query it just rebuilds the list based on the changes. For the hard coded layout, deleting or adding cells would mess things up, so the query keeps things working since the hard coding can keep pointing at the same un-shifting cells.
Only in the last week have I figured out how to create a dropdown that chooses what data to fill in a hard coded layout with. [Hard coded layout always looks at Query A for its data. Based on the dropdown of B, C, or D: Query A mimics the Query B/C/D [which copy data from sheets 1/2/3]. --this is one trick I'm very excited about trying to make use of for some streamlining--
|
 |
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reply
