Im talking about the Bluetooth.Error event.
After sleeping on your data problem, I have some more thoughts for you ...
You are sending a wide variety of measurements, destined to be shown in lots of labels and destined to be graphed in various scales.
You currently request the data in a Command and Control fashion, tightly coupling your requests and responses.
If you switch to a JSON data stream (only 1 or 2 attributes per object to fit BlueTooth message size limitations, short key names to fit, decode using one of the Web component blocks into a dictionary or list of pairs), you can move to a table-driven setup where for each incoming tag/value you can look up:
- which Label.Text shows the incoming reading?
- what multiplicative (default=1) and additive factor (default=0) should be used to scale this reading (i.e. degF vs degC) ?
- what suffix (default "") should be added to the reading in the display ("degF" , "degC", "
Volts") ? - which Canvas should the incoming data be graphed on, and at what scale factors?
- which file should the data be directed to, if at all?
This would eliminate some duplicate code and reduce your block count, and reduce blooper duplication. It also handles missing data more gracefully than counting list indices.
@ABG
You give me so many things to think about. I have never used JSON, I just know it is pretty text-intensive since it is JavaScript.
An approach really worthy of consideration. Give me time to sleep on this (!)
Thank you gain for your time and suggestion.
@Anke,
I see the BluetoothError event is deprecated and that one should use Screen.ErrorOccurred
I will need to carefully reconsider my code for error trapping.
Ok I didn't notice that.
The question remains why this event was not removed there?
I hope I understand you correctly. Why was the error not trapped? It is trapped by the Companion, as below:
Underneath is the blocks for the code as at present. This activates Notifier1 with information about indexing of the lists used.
The indexing works perfectly since the notifier shows:
Apologies for the large images above.
The runtime error is generated because of calling SetVerticalArrangement.Visible to true in the 2nd last statement of this block of code. There is no explicit indexing involved at all in this statement. My lists are therefore working exactly as expected and the problem lies in setting a VerticalArrangament to visible. I suspect I have either run into a bug in the AI2 or I am doing something irregular somewhere else. Are there any checks that I can do to better understand or resolve at all?
If I disable the SetVerticalArrangement block, then the code runs without any error.
Apologies for a fragmented text. If I select any other tab with index > 1, then there is no error. It is ONLY if ActiveTab = 1 that the error shows. The error arises from the VerticalArrangement passed to set.visible. Even if I insert ChartVerticalArrangement79 as the argument for set.visible, the runtime error is thrown. So indexing within this block of code is probably not involved, but the passing of the reference of the appropriate VerticalArrangement to set.visible throws the error.
Have a look at what is happening here: (in the red rectangles)
What does your TabScreens list look like ?
What is the value of activeTab ?
Tabscreens is a list of layouts as defined in the UI/Designer of AI2. See image above.
activeTab is an index (1-6) passed to the method from higher up in the code, determining which tab should be activated. The top part of the above method deactivates any active tab (if present; initially no tab is activated and previousTabNo=0). The middle part sets the appropriate colour and text for the new active tab. The bottom part of the code changes the attributes of the new active tab. Here are the tab layout in the Android UI with no tabs selected. The tabs are just buttons.
Here are the tabs after tab selection:
Something else:
If, in the VerticalArrangement.visible setting in your block above I insert a direct reference to the vertical arrangement (as used in the Initialize Global statement at the top) the error still occurs. If I insert a direct reference to any of the other tabs,(indices 2-6) NO error is thrown. E.g. if I select the second tab, NO error is thrown. I did an experiment by adding an extra element to TabScreens (i.e. list length=7) and do not use the 1st element but start using at the 2nd element (i.e. all tab references are moved one on in the list), then I still get an error when using the 1st (leftmost) tab (ChartVerticalTabArrangement79, now at index 2 in the list) and none of the other tabs raises an error. My conclusion is that there is something undefined in ChartVerticalTabArrangement79 (the layout of the leftmost tab). The reference is problematic irrespective of where in the list this reference to the leftmost tab is located. I hope my argument above is clear.
Oh, and I need to mention that the layouts actually refer to the screen layout in the area below the tabs. The layout does not refer to a button itself.
This would appear as an error earlier, given that you have everything running on one real screen.
Do you run any blocks/code "when" this arrangement is made visible ?
The screen layout comprises 2 parts:
- A spinner allowing a chart for any one of the variables listed in the spinner.
- A graphics area allowing generating a graph. I do low-level graphing because the existing AI2 graph extensions are not flexible enough.
The spinner is defined and initialised in the UI/Designer: no "when" blocks.
There is therefore a spinner.AfterSelecting block that react to events, i.e. after selecting an item in the spinner.
The chart is generated very much in a procedural way using 6 methods that, in this case, really just work as conventional functions: no "when" blocks. The interactions between these functions are managed by one of these 6 functions and there is no event-driven code block while graphing.
The event that triggers drawing a graph occurs when a spinner element is selected.
OK, if we are being specific, how about "if" the arrangement is visible ? 
Possibly somewhere else in the code for showing/hiding arrangements ?
If the chart option is selected, the spinner only affects the graph area and does not enable/disable any layout: the visibility of the graph area is not changed nor the existing screen layout.The management of layouts is done by the tab control code (the selectTab method we looked at today). When a tab is selected, the appropriate layout is initialised and enabled for the area below the tabs and this is exactly where the bug originates. This code is at at a relatively high level. There is some initialisation code in screen.initialize that affects layouts. There are many places in the code where the visibility of single objects (label attributes, colours of specific smaller elements) are manipulated, but not the attributes of associated layouts. I hope this answers your query?
Hmmm
I have just taken a look at your project again, and you do actually have quite a lot going on when you click the ChartsTab button....
If I remove the "bluetooth blocks" then I get no errors and the spinner dropdown displays as expected, without any errors about lists.
There is plenty of "list" action - ifs/while/forEach along with selections from lists and indexes in the "bluetooth blocks". The issue could quite possibly be there.
Suggest you remove all the blocks from the ChartTab.Click event, and then add them back one by one, until you find your error.
Thanks very much. Please give me a day. I am working to resolve this and requires a bit of time.
I have been doing quite a bit of testing. Here is what I found.
-
In the ChartsTab.Click event handler, I disabled all the code except for the call to setTab (the very first instruction in this event handler). Problem still persists; the runtime error is still shown. This suggests that it is not the list mashing inside the handler (and accompanying memory management behind the scenes) that results in the error. Rather, the call to the setTab method is the problematic statement.
-
In a separate test I changed the code so that the history data are from a CSV file (added to the asset collection) instead of from Bluetooth. This eliminated the Bluetooth infrastructure for this part of the code. I could not keep perfect one-to-one comparability of code because the CSV file produces all the lines of data all at once, while Bluetooth provides the lines of data one line at a time. Still, only a few changes to the code were required. No solution. The runtime error persists exactly as before.
-
This leaves the seTab method. The offending statement is the very last one where the verticalArrangement.visible is made true for the appropriate layout manager for the area below the tabs, depending on which tab has been selected. The different layouts are defined in a list of layouts (Tabscreens). However, it is unlikely that this variable management is at fault. The reason is that if I request the layout "ChartverticalArrangement79" directly and explicitly, as follows:
then this instruction still throws the runtime error. If I substitute any of the other layouts in Tabscreens, then the runtime error is not generated. The error is due to some initial setup of the objects. This clear from the fact that the error only occurs the first time the chart tab button is selected. Afterwards, selecting the Chart tab does not generate the error.
This brings me to two questions that I cannot answer.
- Am I barking up the wrong tree by focusing on ChartVerticalArrangement79, looking at symptoms of a deeper lying problem?
- Is there any way to determine whether the problem is within the initial setup or handling of the VerticalArrangements in the program (accessible via the Blocks tool) or whether the problem lies in the way the object definitions are defined in the Designer? If the error handling software showed which variable was being manipulated in an invalid way, it would greatly facilitate solving the issue, but it looks like this is not possible, because this runtime error does not trigger any of the conventional error trapping code (e.g Screen1.error).
For the moment I am at a loss.
Thank you again for your time with me and your patience with me.
All a bit weird 
In my tests, with chartsTab set like this:
On first click it generates the error. if I click another tab, then click the chartstab again, there is no error.
I then tried reloading the app and clicking a different tab, then switching to the chartsTab, I got the error.
Then tried this in the chartsTab (the green block is the next one down in your aia):
reloaded the app, clicked the chartsTab, and no error.
Try continuing to add blocks back from this point, testing each time, to see when the error arises again?