Couple of improvements here:
1. Previously, ProgressProc was called whenever the LZMA encoder decided to report progress. This usually worked OK, but with some settings/data, there could be long delays between each progress report, e.g. half a second or more, and this made the IDE's UI slow to respond. Now, instead of waiting on progress reports, the main thread wakes itself up at a fixed interval to check for progress changes.
2. When progress was being reported, the worker thread previously waited until the main thread finished handling the event. (I can't recall exactly why it did that; it may have been an attempt to improve UI responsiveness on single-core systems by effectively forcing context switches.) This wait has been eliminated, allowing the main thread to update its UI while compression continues concurrently.
Previously, it checked if the input buffer was empty and then if NoMoreInput=True. That's backwards; the input buffer could become non-empty in between. If that happened, compression could end with that remaining input unprocessed, leading to a "Setup files are corrupted" error.
It's likely nobody ever ran into this, though. I could only reproduce it by adding a Sleep between the input buffer and NoMoreInput checks, and a Sleep at the end of StartEncode.
