Regarding those global variables, here is a version of the code without them, using only local variables, so there is only one version of the truth, as filtered through my run time procedure:
It runs the same, so no demo.
To debug, instead of applying Do It to global variables, apply Do It to value procedure calls.
I am striving to assimilate the lessons from your code. Thank for that, and for your patience.
Okay, so I did some experimenting with creating a local variable for the listView.
...this seems to be working!
a) "old" goals are showing up in the ListView upon the screen being initialized (that's the first time we've had that result. Finally!).
b) new goals show up in the ListView and are even separated by a the "|" .
c) Existing goals get deleted by clicking the Delete Selected goal button (Which we we haven't discussed it in a while).
d) Screen 06 is now not working (as to be expected), but we'll worry about tha
e) so I think the big lesson here is that, with things like ListViews, local variables are the way!
Thanks for your help! Onward to screen 06 (which is where the problem originally reared its head)!
Beware those global lists.
TinyDB should be your only trusted source across screens.
Hi all. Here is my progress on this app so far.
a) So ABG might be proud to learn that, on Screen 05 I have reduce (though not eliminated) usage of global variables. Behold:
b) I'm also striving to move over to ABG's style of using procedures-that-get-called more than just doing the process within the control (like when-do). Little by little getting there.
c) Now that I have Screen 05 working, the code for Screen 06 that ABG generously provided for me is 1) throwing errors and 2) no longer populating the ListPicker with roles. First, I am getting this error:
The variable $role is not bound in the current context
I've been trying to figure out the source of it for a few days now. Though I only partially understand ABG's code, I can tell it has to do with this section:
We have the procedure role getting defined, and then being called. But it is throwing that error.
d) perhaps that has to do with the prior problem: roles not populating the ListPicker. In the blocks, the ListPicker should be populated with this code:
...that's the roleName procedure, which looks fine to me. Then, the code for the ListPicker calls the roleNames function:
I honestly don't know why it doesn't work.
Thanks in advance for reading and any help.
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
