Glenn, can you explain this bit. I tend to use threads, whenever I can (if there is a real advantage). I Don't have any problems with using TThread...
Uhm, it's been quite a while since I seriously played with TThread, especially since I sought other methods. But from what I know/remember of it (and looking at my old sample to answer the question above), my observations:
1) Trying to get it to work right. Too many i's to dot and t's to cross. Too many "it looks right but does nothing" moments in the two programs I did with it. Ultimately I found it to be too much effort for the return.
2) Requires a separate unit in most implementations to get the general framework down. Not a simple "fire it off" affair. Again, much work, little return.
3) For most implementations I've done where threads could be useful, Application.ProcessMessages; let the functionality be sufficient. Of course, there are problems with A.P which are eliminated with threads, but not so much that I have noticed. Again much work, little return to do thread.
4) Separate unit, and the way it is implemented raises complexity. What if I have five or ten thread routines? Five or ten units? I could copy for #2 and this point, but it doesn't work out very well with how the design is or the expectation.
5) Not very extensible - I'm thinking extensive multi-threading solutions with an eye to multi-processing. I have a multi-threading quicksort done (not sure if I still have the source or where it is) - that was tricky enough to get my mind around. Nevermind trying to do it with TThread.
6) What can you do and can't do within TThread? That's one I've run into almost constantly where code tested and working outside of TThread doesn't work right in TThread for some reason. I don't get that with BeginThread/EndThread.
7) I don't know this one for sure personally, but I've been told TThread is hideously inefficient if you hammer it enough within routines.
From what I read in different forums (Usenet Delphi, Borland's and others), most people tend to push towards using A.P; or BeginThread/EndThread along with some adapted procedures for other tasks, like Suspend/Resume and changing priority - and I've been heavily urged in posts there to do the same (to the point of parts of TThread - primarily Synchronize - being described as "doing next to nothing good").
Actually, I'm pretty interested in what you think - what do you see as the advantages and disadvantages of TThread, Application.ProcessMessages, and BeginThread/EndThread?