OK from the list block you noted 2 responses up I went to the associated link about functional blocks. From this it seemed the most useful approach for this situation would be the filter block. So I filtered the iscurrent block as below with the offerMadeToViewer block using blocks from the Intersection construct provided earlier.
This gives me a correct [9] response when I Do It to the subsequent currentOfferedToViewer variable.
Unfortunately as with previously using the Intersection block it's coming up just [] when I run or rerun the program.
Is this some sort of timing problem? If I used the clock to put in a delay before the calling the currentOfferedToViewer variable would that give the filter block above it time to run and come up with the [9] answer? Thanks again for your help.
Each post explores a tiny bit of the problem, without access to the whole project and base database.
Could you post a link to the test data spreadsheet to allow exploration of all sheets?
An exported .aia file would also help.
If you need to guard your sheet access, then full block images of all events are needed, no code fragments, or remove your .json security file.
This does sound like a timing problem, or confusion between row ids and rows.
filtering the column data through a comparison against the current date in MMM d,yyyy format.
Because the formats don't match, the filter will always return empty.
I prefer yyyyMMdd for a date format, because its number comparisons match its temporal comparisons.
Also, that global row counter should be initialized at the top of the loop, for clean reusability.
In Screen1 you issue a read range of sheet Offers, for range H1:O1
I assume the rangeData comes back as a list.
Your loop through the raangeData ends up with TinyDB tag offersUserList containing just the last item.
Each pass over the list replaces that tag/value with just the current item.
Maybe you wanted to just set that tag's value to rangeData to keep the entire list?
I'm bumping up against supper time here.
Sheet Offers has the names lined up across the sheet.
That's a problem if you want to scale this up or add and drop names.
I had mentioned earlier the idea of turning columns into rows using the equivalent of a JOIN table.
Is that idea still in play?
P.S. Before I break, here is an old, obsolete food trade logger based on a no longer available component.
I mention it for its table structure.
Ok I'll have a look at the Pizza Table approach and get back to you. Does
'supper' mean you're not back till after a night time break? I'm in NZ and It's lunchtime.
Yes I realise the column per foodbank provides scalaibility problems, but it's the only thing I've found that will work. The Receiver and Users Spreadsheet tabs shows a separate approaches to addressing this.
I think the offer visibility criteria (expired, viewer in list) can be consolidated into just one column of the offers table, instead of all those individual viewer eligibility columns.
The trick is to use the read with partial filter block instead of read with exact filter. The partial filter would check if the name of the viewer of the offer were in a comma separated list of eligible viewers in that offer's eligible viewers cell. (I assume cells can stretch to include such long csv lists.) To throw in expiration, wrap the viewer list with a =() formula that checks the current date against the expiration date of the offer, and returns blank if expired, the viewer list otherwise.
I haven't had a chance to test this yet.
If it works, it would open up the app to unlimited agencies while reducing the code considerably.
ABG, putting this in here rather than main thread as keep getting an error when trying to send.
Ok, that certainly makes sense, particularly in relation to allowing it to work with unlimited agencies. I'll try this in later iterations of the program, probably with a move to sticking the data in JSON.
In the meantime I've tried and got to work a completely separate approach (see below). I've
selected the entire offers sheet so it comes as list of rows of lists.
I've then put each of the separate row lists into TinyDB and so I have them as offerList1, offerList2 etc.
This allows me to run a loop through each of these offerLists, to check whether a) the index for the current viewer returns 'Y', and if b) the index item for whether the offer is current returns 'current'.
Anyway even if a bit 'clunky', it works!
Thanks so much for your help here though, it's been a long exchange. I'm assuming you work for MIT AI, or are you just an enthusiastic amateur. If the former, and if appropriate, send me contact details for your boss, and I'd be happy to give him positive feedback on the work you've done here. I'll throw a few $s at the donation site.
This really has saved my (posteria word beginning with 'A' MIT won't let me use)! God Bless!