the thread should be able to set the text on that dialog
That is the problem !
Don't push the info (or data) from background thread to main thread or
GUI (
VCL), let the
VCL/
GUI poll the status from the threads, but if it is necessary then notify by (well highly recommended) a message, also make the thread limit its notification to time based condition, like lets say we are moving/copying a folder, if that folder have 10k of small files, it makes no sense to notify or update the UI for each of them, right !?, the copying thread will notify once every 1/10 or 1/20 of second and when finished, and that it is, or will not notify anyone/anything, thread is doing his job and updating single place with data, UI will update with timer, here if the
OS itself is way overwhelmed with other application or the CPU is very slow, the application and its UI will not block and will not fail beyond what the
OS allow it, but will recover nicely when CPU (hardware in general) is relaxed.
A modal form can block the
VCL/
GUI/UI.. and show "please wait.." or "working...", while have a timer to get the current status/operation form the worker threads, here you don't need to time your background threads or their operation, they just updating a list (may be a list, or properties ... whatever) in thread safe way, while your dialog or modal form will have a timer and update.
one problem though if the thread operation might take long time and can't be cut or sliced in shorter job, (as example coping 8GB file on SSD or HDD) then nothing can be sliced and here you need to switch to overlapped file operation,
https://learn.microsoft.com/en-us/wi...put-and-output
Also look at this nice answers
https://stackoverflow.com/questions/...fast-file-copy
Notice also these are not utilizing the overlapped IO, yet these operation (reading/writing) can have it and you can have timeout on any of these operation, also as in the second answer 512KB buffer while the first will be very slow with 1KB, i would suggest to try to perform a read with less than 64KB on any modern hardware to not waste time, and 512KB sound good too with modern hardware cache buffers, in all cases if one of these operation will block for long time then you need to switch to overlapped and use them exactly as sockets !, you call the operation with overlapped structure having an event then poll on that event, in such design you can cancel the operation any time.
The code above can be adjusted to run in background thread and store the current filename(, size, position...etc) inside the thread itself, while your
gui with a timer will update the status.
I keep telling that : you should not push form a background thread to main, because i saw this many times, code working perfectly for years, here comes new faster and powerful hardware makes things light speed for UI to keep up, that working code in the past is overwhelming the UI, that happened not because the developer was short sighted, but hardware changed and evolved, few months back i fixed a code (not mine but been asked to modernize it) was working for ages, now it fail with unexpected behavior because the client (owner of that legacy software) started to use hardware with SSD and 2.5Gbs connection, in the past it was on HDD and ADSL.
Hope that helps.