While I have received quite a bit of help on this project, I haven't quite figured out how to associate a list of tags with a list of checkboxes. The tags in this case are colors but they will eventually be data points. Right now, when the app is run, you can enter any combination of checkboxes, click "Get Data," and see the boxes in the order of selection. The boxes are currently deselected by unchecking them. I would like to learn how to associate a tag or data point to these checkboxes before they are saved in TinyDB such that the tag or data point is recalled with the saved checkbox sequence. What I am trying to accomplish is to have a particular color show when a checkbox is selected instead of the number "0".
I think I need another list but I already have lists coming out of my ears. Would someone kindly direct me to a cogent example or show me how to make this leap? Thank you.
I'm sorry about my lack of sense - I am just trying to gain an understanding of how everything works. Sometimes, I deviate from my original purpose to try to learn or embody something. I hope the attached .ala makes a little more sense. Basically, when my checkboxes are saved in a particular, I want to save the associated data (MyCheckBoxes) so that when the app starts again, the checked boxes have content to display. With this particular .ala, my expectation is for the number "10" to be returned when text label 1 is selected in the list. Right now, the default is "0" because I do not know what I am doing. I am trying to associate data with the checkboxes that is saved when the Tiny DB data is saved. Thank you for your patience with me. The fact that what I posted makes no sense to you shows how removed I am from this process.
I think I can have it all (I think I can I think I can . . .)
Thank you for your patience while watching me run in circles, as my selected check box text and functions were already saved to a text label - As you were trying so hard to point out, my data is already there!
Selection_Display_Label.Text contains all selected check boxes (four shown on the MyCheckboxes block for brevity).
I still, obviously, do not fully grasp the storage/retrieval of TinyDB data. I believe I am storing the data to TinyDB1 at the end of the Get Data block but I am unable to retrieve the data with the tags - just zeros.
I hope that the attached images and code blocks might allow you to see what I am doing wrong. As I have learned, it takes very little to disable an app. If this makes little to no sense, I can create some design code to put it into perspective. Thank you, again!
Wow, I am humbled by your knowledge and grateful for your time but I cannot figure out how that block code can apply to me. If you have the patience of Job, perhaps you will look over the attached code and block image question?
The code is truncated but works as I would like it to, in that it displays the requested data in the order requested. If you get an error message, the WIFI signal hasn't connected yet. Pressing either Metric or Imperial and then NWS will allow the entry, in any order, of up to the four data points. Get Data takes you to the label where the data is displayed but that is where I am lost. Referring to the block image, do I want three TinyDBs, one each for NWS, ATMO, and CALC? That would allow the user to call up specific saved data from one of the three sources. As you can see, I have created some buttons that do nothing at the moment but that I would like to have save data for future recall. It would be ideal to be able to save a list of data points from each source: NWS1, NWS2, ATMO3, CALC6, etc., but I would be happy now to have a single text label saved for each of the three sources.
If I want to use the code you created and have each data source be in a separate dictionary, I believe that would work, as well and allow me to understand dictionaries vs lists a little better. Thank you for any direction you can lend. It will be greatly appreciated.
I would be happy (for now) with only the latest reading but, for more complete functionality, time-stamping data would be a hoot and a half - right up there with a British Bakeoff upset;). If time-stamping could be an optional selection, multiple needs would be met - from a basic reading to a chart to plot trends over time.
I understand and deeply appreciate your knowledge and time. If you are willing to get me started with, say, the NWS data and drop hints at how I can replicate that over the other two sources (ATMO and CALC), I will repost the code with the corrections when I figure it out for the benefit of others. Again, thank you from every last neural connection in what used to be my brain. With deep respect . . .
I will do so before I go to sleep, and refresh myself in the morning. I have no need for multiple TinyDBs if everything I am seeking can be done with one and I surely do not wish to overly-over-complicate this. I will read the link and sleep on it.
If you want 3 separate data sources and do not intend to mix them, you could set up 3 variant global variables each for the inputs to that generate_YAML function, one checkbox list for each source and one readings_values dictionary for each source.
That's the nice thing about writing reusable functions with parameters. All you need to do is feed them different inputs and route the output to the right place.
OK, that was a quick read. Your solution seems the more elegant (and simpler) of the two. I don't quite know if I entirely grock what you are saying but I will study and follow anything you may be kind enough to generate and share with me. I kind of get (I will be corrected by your example, if necessary) that you are speaking of having a master list that has three sub-lists in it (for NWS, ATMO, and CALC), each sub-list being capable of storing and time-stamping a multiplicity of Selection_Display_Labels that are updated on a regular basis.
Please understand that, even if I am remotely close to being correct, I have absolutely no idea how to accomplish this task other than (gently) falling on my knees and beseeching you, a power user, to show me the way ("Luke . . . use the force!").
I really get emotional when I think about how much you, and other power users, have helped me in the last few months navigate an entirely new form of code (for me) and to begin to make sense of a code that, if learned as a pre-teen, would make me a master-power-user (in my wildest dreams - I haven't received any offers of "re-do's"). .Thank you, again, for all of the assistance and guidance you have provided.
Now would be a good time to review the list of AI2 Anti-Awards.
Aside from that, here are some general observations.
When you are cooking a data recipe which requires ingredients that have to cook on their own before being added to the pot, order of operations is important.
AI2 has several components like that, which need to trigger their completion event before their output data can be used:
Location Sensor (GPS)
Web component (GotText)
Bluetooth (both flavors).
So if you are asking a Web Service for the local weather, don't do that until you have actually received the location from the Location Sensor.
The don't try to do any work with the weather values until they have actually arrived from the Web.
Regarding your app, I believe it has exceeded a comfortable complexity level.
I recommend splitting it up into separate single purpose apps, to reduce complexity.
You don't need a one man marching band.
Bingo! But how? I googled several variations on the theme but nothing came up. I assume you are speaking of separate apps that, somehow, work together as a cohesive whole but if not, I do not see how I can offer this in several separate downloads to anyone. The app gets data from three places, allows user selection and storage of requested data for immediate recall or timestamping - it seems like a single app to me, but it is getting highly unmanageable as the slider on the right side of the blocks window gets smaller and smaller. Please let me know if I am missing something here. Thank you.
Oh yeah, in the mega-app version, the user is instructed that the local NWS station will be displayed upon connection. Then the location shows and the app tells you it is connected. This way, users can proceed to activate the Bluetooth LE scanner and/or enter user data in the calculator while awaiting the local connection.
