gfx/progress_window.h

For an application, not a plugin

A plugin must not open a window of its own over the host (see message_box.h); a sampler loading a large file composes ThreadPool, Overlay and ProgressBar inside its editor instead. This is the reference's object for programs that own their process.

How the pieces talk

The job runs run() on a std::thread and reports through setProgress() and setStatusMessage(), which only store (atomically, or under a small lock): the window copies them out on its own 33 ms clock, on the message thread, because a component may only be touched there. Cancel raises the job's ThreadExitSignal -- the same one a MessageManagerLock taken by the job gives up on, so a job blocked on the message thread is not a deadlock either.

When run() returns, the thread queues the ending on the message thread: the window goes, and threadComplete(userPressedCancel) is called from the queue rather than from inside the window's clock or the button's click, so it may delete this object (the reference's usual "delete this" in threadComplete).

A job that ignores the request to stop cannot be killed -- a std::thread has no safe way to be -- so after timeOutMsWhenCancelling the WINDOW goes, and that is all. threadComplete(true) still waits for run() to return: it is where this object may be deleted, and run() is running on it. Called "anyway", as it once was, a delete this there freed what the job was still using (AddressSanitizer: heap-use-after-free in run()). runThread likewise returns only once run() has.

RUN on Windows: a modal runThread to the end with the bar checked in the window's own pixels; a launched job cancelled by a click on the drawn button; and the time-out. The window is a DocumentWindow, so it is compiled for macOS and X11 with the rest.