Apply Do It to see what is coming back from TinyDB from all those different tags.
Also apply Do It to those function calls to see what they return.
Also apply Do It to whatever .Selection values you get after selecting.
Then post them here.
Also I suggest making this change to the role(roleName) function, so that it always returns some kind of 3-element list, even though the role name it was given does not appear in the roles table.
Draggable
Okay, here goes me doing Do it and posting screen shots of the results:
a) Do It on the DB .getValue in the .Initialize screen block:
...it pulls DB info on role names, role vision, and role definition of happiness
...returns an error (a red circle with an x in it). So we have a problem here.
...does indeed pull goals values from the DB
....does succees in pulling role info from the DB.
....yields is an error (red circle with the white x) so we have a problem here. No wonder it is not working when called in the intialization block because it is not even working in the "pure" function.
...is giving an error.
...is giving an error.
...is giving an error
This is probably all the result of one place in the code giving an error, but I am not yet good enough at unit testing to see exactly where that is.
These blocks depend on the TinyDB values returned for tags 'roles' and 'myGoals' being tables (lists of lists).
Unfortunately, Do It does such a good job of text conversion, that you can't tell if the original value was a list or not.
You can test my guess by applying the 'is a list' block to the TinyDB output values, in a Do It.
Then you can test if they are tables, by trying to select items from row 1.
Here is a draggable less gullible version of the roleNames procedure:
By the way, Do It does not work inside procedures, since their data is fleeting.
To test procedure code, copy the guts of the procedure out, and feed the guts directly from TinyDB or global variables.
Apply Do It to expressions, right to left.
a) I'm deeply appreciative you taking your time to put together these blocks. But they don't work.
I'm at that place that I suppose many programmers have been at with this: I'm on the cusp of giving up. I've been working on this problem for a month now.
What's frustrating is that: in a spreadsheet or a MySQL, this would be 30 minutes of work. This is a pretty simple query:
SELECT "goalName" from goals WHERE "roleName" = selection.
I kinda regret doing this in TinyDB. It isn't meant to be relational. Perhaps things would have done better with learning Firebase.
I know this is self-pity but, I'm starting grad school on Oct 1st and I really wanted to have this app done by then. On that date, my focus will change drastically.
Thing is, my instinct tells me I just a few changes away from getting this thing working.
b) You said "These blocks depend on the TinyDB values returned for tags 'roles' and 'myGoals' being tables (lists of lists).
Unfortunately, Do It does such a good job of text conversion, that you can't tell if the original value was a list or not."
I think I can affirm that TinyDB is really storing true "lists of lists" and not just blobs of concatenated text. I have proven than elsewhere in this app by pulling specific indices from the DB and pushing it to ListViewers.
Seeing how you know SQL, you might consider looking at
(which I don't support, though.)
Could you upload your latest aia export and remind us of which screens work, and show us some sample data?
I want to make sure those advanced list blocks are not misbehaving with direct TinyDB output.
Either way, good luck in grad school!
Thanks!
Here it is.
I'm not sure in what form you would like me to show you sample data. On the version in my emulator(on my laptop), there are just a few entries for each table. (role, timeframes, etc).
These screens work:
Screen 1 (Main Menu)
BE_Menu
BE_Define_a_Role
BE_Define_a_Timeframe
BE_Goal_and_Big_Rock_Define
We're trying to get BE_Role_Report which summarizes data from those last three screens.
BE_DO_v0_2024_09_07.aia (44.7 KB)
Thanks in advance for any help.
So I'm doing some unit testing and...
a) checking to see whether global roleTable is a list returns true.
b) running a notifier give me a notification that "roles is a list", as seen here:
The next step is to figure out why the ListPicker is not populating with role names.
This is probably an "index" issue.
So I woke up bright and early this morning and decided to treat this as a honest-to-goodness real problem in life; I drew up a problem tree focused on disaggregating the possible root causes with this code.
Here is the whole problem tree (which is probably too grainy to see) :
Here is the problem definition:
Here are the disagreggated possible root causes as to why the Roles ListPicker is not populating:
Here are the disagreggated possible root causes as to why the Goals ListViewer is not populating:
Now, some possible solutions:
Thanks in advance to anyone reading this,
Wow.
You have put a lot of thought into this.
What are you majoring in?
I guess I had better get to work making up my own test data.
For better or for worse, I have. I'm striving to become a good problem solver this year.
Business Analytics.
Any insight you can provide would be greatly appreciated.
On my end, I'm going to experiment with creating a straightforward procedure to loop through global roleTable manually and select only the role names, then populate ListPicker from this simple list of names. This might help rule out whether the map block or list indexing is the issue.
Thank you.
What about using the local sqlite database?
There are extensions to access it, for example App Inventor Extensions: SQlite | Pura Vida Apps, which follows the KISS principle - keep it simple, stupid... there are also other sqlite extensions
Taifun
Thanks for taking a look.
The error it gives (although now it is for procedure roleNames2, a newer version of this procedure) is the same error it has been giving for about ten days now: "The variable $role is not bound in the current context".
This is the function, as it currently stands, that is attempting to feed that ListPicker:
Do you also get that error, if you try a Do it on roleNames?
Something in that procedure is not correct then...
Taifun
Lol, your vision, DOH, and Big Rocks are hilarious for this role.
Testing now. Many thanks!
These are caused by trying to apply Do It to local variables.
Those are garbage collected when the procedure ends.
Instead, set up little test tubes fed by constants.
Here is a procedure you can use to make your Elements look better than what you get by forcefully jamming a table into an Elements list:
ABG, the core functionality on this MVP seems to be working. I'm very thankful for your help.
I'm going to spend a few days tweaking features and then release the MVP to see what feedback I get.
