Dave, in Web it is not a problem to do UI access in a webthread. So you can indeed populate your WebListBox in a WebThread.
Well, the subject still comes up from time to time. Xojo Web and Xojo Desktop may look alike somewhat, there are intrinsic technical differences. Thread < > Webthread being an important one.
Don’t do that. The data probably won’t arrive at the browser in the right order.
Not necessarily. You can perfectly create a subclass of WebListBox that has a built-in populate method that takes an array, and a timer that will feed it to the WebListBox, so code duplication will be reduced to the minimum.
That is not good. Do not do it.
Greg, who works on Web Edition, has said not to update the UI from a Web Thread.
https://forum.xojo.com/36229-web-edition-accessing-sessions/p2#p297581
I understand you’re trying to find the fastest way out of the situation you’re in, but I am concerned about sharing bad practices for people who are searching for answers here in the future.
@Greg O’Lone,
Is the WebThread issue with Listboxes similar to why I’m getting the javascript null errors within a WebThread when I embed a new instance of a container and then try to set the value of controls on the container?
Is it trying to set the value of a control that doesn’t technically exist yet?
Very possible. Mind that a round trip can take up to 200 ms while your code will try to set the value the next millisecond.
The key to rock solid Xojo Web I find, is to never assume anything has already taken place, without giving it time to actually make it so. For instance I very seldom do much in Open, more often in Shown, because at that stage, I am sure the control exists.
For your stuff, that could be a good trick. Implement the Shown event for the WebContainer with addhandler. When its shown event fires, you are certain the control is fully operational.
Thank you Michel. Testing that idea.
Incidentally, reading again the thread, I think the listbox update in a thread is a perfect example of what Xojo Web is : everything is asynchronous, so expecting that things have taken place is potentially dangerous.
In the ListBox update thing, I believe a way to go would be to add a row, then check if it is there, then send a new one. A handshake mechanism.
Something like that should work :
- Addrow
- Check the row has been actually added with LastIndex
- If LastIndex has moved, do another addrow.
Since there is no event that signals the change is complete, a timer to monitor the change seems to be the way to go.
That means directly updating the listbox is probably not the right way. It seems preferable to first build a queue in an array.
I always do my UI updating inside the thread and have never seen the ListBox order change from the expected value.
I had more problems (JavaScript errors) when I once tried to pass the results to a Timer after the thread had finished, where the Timer was updating the UI from a string array, so moved it back inside the thread.
If you make sure the change has taken place before sending a new row, it should be an issue. Otherwise, what happens to Dave can occur, because on the Internet, it is intrinsically impossible to predict the time it takes for paquets to get to the browser.
That said, if the process is slow enough, it should not be an issue.
Keep in mind what I call the “ping principle”. Try to ping your own server. Mine for instance has a ping of 148ms. That is the bare minimum for a round trip of a few bytes. Anything more complex will take longer.
We are far from Kansas…