I you do apps for yourself that always do things in expected ways, or depending in what you do, is ok. Controlled risk with technical knowledge.
If you use it improperly, as most people will, people will click on buttons that usually should not be clickable due to UI activation in a improper time, controls that should not be refreshing at some point will, etc. Events out of order, UI side effects, etc.
I don’t use events directly with threads.
I usually create a class where I implement for example the tcpsocket with Threadsafe functions.
Then threads that will use the object created from this class will have to poll to get or write the data without worrying about threadaccessingexceptions
As Eric says, just use the std pipes that are already there, rather than adding an additional overhead and complication.
I do this all the time with helper apps. With the Xojo shell class you can capture what the helper prints out and you can send it instructions or pass it launch arguments telling it what to do.
I would seriously urge you to consider using other tools for helper apps, the difference in performance is incredible. The helper in the up-coming Sleep Aid completes all of it’s work, before the Xojo made version has even finished launching.
It is also worth noting that environments such as the Mac App Store, may not approve of the use of TCP sockets. That’s right, I know a dev who had to fight to get approval to be able to print.
The other method is XPC, but doing that from Xojo… I’d rather poke out my eyes with a blunt spoon.
I always split it up and use compiled command line apps that I call from the interface app. They run completely separately and terminate when something happens - i.e. database change. I have up to 20 apps running, all co-ordinated by a SQLite file, interface done with a minimal footprint desktop app. No hassle.
I just ran into this problem, it’s shocking. I have some hardware communication which takes approx. 2 seconds. I realized the window freezes that period so I did put the code in a thread but it gets even worse because now not the window but the whole communication freezes if I dare to move the window.
I see there is a new preemptive thread mode, is it solves a problem like this?
Yes. A well designed preemptive thread always run without blocking the main thread… UNLESS needing to access some BLOCKED resource shared with the main thread, and that resource is taking time to be released. Usually you will be on the control of the resources, and ultimately you will be to blame for this, not always, but almost always.
