I understand that Updating UI via a Thread is not possible and have implemented the Timer to update the UI which works okay. But it seems ridiculous that just Reading values off the UI is also not allowed which kind of make it very restrictive and hard to work.
I have a listbox which contains files and user inputs which I would need to itinerate through and read in the values to process but not being able to even read the values just makes it almost impossible to work.
It seems like the only way would be to create additional processes perhaps to temporary duplicate the listbox into an array or sqlite table just to get around the UI and Thread issue. I am not sure if this would add to the overhead.
Is there a better or elegant way of getting around this UI Read/Thread restrictions apart from abandoning Xojo and going back to RealStudio 2012 ?
If you really understand the issues of thread safety, it doesn’t seem so ridiculous. That said… The straightforward way to handle this is to create a subclass of Timer, call it ListBoxTimer. In the timer’s action, make the changes to the ListBox that are queued up, then read the values you need and store them as properties of ListBoxTimer for easy access from the Thread.
If the contents of the listbox aren’t supposed to change while the thread is running, copy the contents of the listbox into an array before running the thread. The thread can use the array instead of the listbox.
Tim’s recommendation is the path I took when I threaded my apps. Since the array members align to the list position, accessing theArray(theSavedListIndex) is the same contents as the selected line in the listbox. However, I’ve had to get fancy with a multi-selection listbox where I have a separate variable that contains the selected listindex values.