- Tue Jan 31, 2017 4:36 pm
#61837
I was merely suggesting a possible way to get past a vars limitation if that was a problem, but if the vars limitation is not a problem then it would cause unnecessary complication.
So here's what I was thinking just in case...
If I've understood mmiscool correctly, there is a limit on how many variables you can use, but it does not include arrays.
So rather than define all the different alarm On and Off times as individual variables, you could have more room for more if you bunged them into an array.
Esp_Basic doesn't have multi-dimensional arrays, but it can have multiple arrays. So you could use similarly-dimensioned On and Off arrays, with corresponding 'enabled/disabled ' status arrays if that's how you chose to do it. Doesn't matter how many alarms you have, cos you would only ever be using a single cell's currently selected data at any one time. And when you access that cells data to change the alarm time for instance, it would only be that single cell data that would be winsocked to the browser.
Your GUI could still function as it currently does, but only on the currently selected alarm at any one time, rather than all jostling together side by side.
Obviously array data loss could be a problem with power fails etc, so the array data would need saving to non-volatile memory. It might be possible to treat all the different alarm times as different saved files, but if not, then all the arrays data will need saving into a non-volatile var string.
When reading that string back, if you know how many words are in the string then you can easily do a 'for count = 1 to words' operation to extract them. But if not, there is no WordCount function, so you will need to sequence through the WORDS while counting a DO LOOP UNTIL the WORD(count) = "" (empty cos it's reached end of string).
Parsing strings of words for different things is problematic using just the Word() function because there is no way of relating the WORD(count) result string to the corresponding original underlying strings characters. So you would need to set up a nested inner WORD() search on the results of an outer WORD() search (which can get rather convoluted and difficult to mentally keep track of for troubleshooting).
For that reason you'd probably be better off saving the different types of data to different strings, ie: On times to an ONstring, Off times to an OFFstring, Alarm Status to a STATstring etc, each of which is much more easily managed, rather than trying to extract them all from the same string.
The array could be sequenced to display/edit all alarms in turn, but only the currently selected alarms data would be accessed by the browser at any moment no matter how many alarms were defined and in use.
I think that may be relevent, because I suspect the 'busy' browser page may be more of a reliability issue than the vars limitation.
