Yes. That’s true you can do that. Good idea…
Here’s an example for URLConnection…
URLConnectionDelegate.xojo_binary_project.zip (5.3 KB)
And don’t forget that when you’re creating these things in code, that you can right-click on the class name to automatically add methods from events and delegates with the correct signatures…
Edit: Fixed a syntax error in the project
4 Likes
Never knew that!
Ditto. too!
That’s freaking cool! WOW!
From your crash logs, it looks as if the problem happens when an object is destroyed, as if the destructor for an object (which was created outside the thread) is being destructed within the thread.
Could be a framework bug, but I’m wondering: Could you have a bug where the thread is holding onto a reference to something in the listbox that it should release?
Nope. I don’t think so. I will double check. It is a good thought.
I was putting together an example project to try to duplicate this and I realized something.
In my project I am using the “classic” Listbox and not Desktop Listbox. I am guessing that Xojo is not ensuring that deprecated controls are preemptive thread safe and that’s what I might be seeing here.
Is that a valid thought? If so, that might be something that forces me to finally upgrade to API2 controls…
I don’t think so. No GUI control is thread safe, neither cooperatively nor preemptively. The UserUpdate event will always run on the main thread, and that’s where a thread should manipulate GUI elements.
Of course the UI can’t be updated from the thread. But if you look at this thread here on the forum, you will see that I’ve had issues with the Listbox (classic) and painting the cell text while preemptive threads are running in objects that are attached as row tags of the listbox.
I’ve been able to successfully cause this crash now in Windows when doing a similar thing using the DesktopListbox. I am not seeing the crash yet on the Mac with this example.
And I’m not touching anything in the user interface from the thread nor am I touching any objects used by the thread.
I don’t know what it means to “run a thread in an object”.
1 Like
The thread is a property of the object.
Sorry if my descriptions don’t meet proper programmer syntax. 
Well, perhaps I miss something but that there is a reference to a thread in an object should not be relevant, even if that object is referenced from within a RowTag. What a thread should not be doing, AIUI, is referencing any property of an object that is part of the layout. I’m not sure a thread is allowed to even read such as, say, the width of a rectangle.
Exactly! And it isn’t touching anything in the UI control.
Well, William just confirmed an issue with Listboxes and threads:
having a ListBox header causes other threads that modify their images to crash.
Glad to know I might be goofy but I am not crazy!
2 Likes
Here’s a real world example of what I am doing at one of my larger customer’s. It’s a hockey arena in Florida. It has 260 displays throughout the arena and 60 different video sources. I can view everything that is showing from the PC. Below are a couple screen shots. Think about how many different concurrent threads are running processing bitmap data that’s sent to the PC by the device connected to each display…
What is currently on each display:
What is currently on each source that can be sent to any display:
The images are small, but you can click on any image and have it enlarged to the full screen, adjust captured resolution, etc.
This was not possible before preemptive threads. The system would grind very slow. Now we can update somewhere close to 10 frames a second.
7 Likes