🚀 go-pugleaf

Hi all,

I'm currently working on a single threaded application that makes
extensive use of legacy libraries and 3rd party DLLs for file
import/export/conversion, operations that can sometimes take rather a
long time.

We currently have a 'busy' dialog withn a cute animation, progress
bar, status message and cancel button that we show when running a
lengthy conversion, however it's user responsiveness is rather poor as
it relies on application.ProcessMessage calls from callbacks in the
conversion libraries, which are not provided in all libraries and even
when available are not always called as often as one would like.

I would like to improve the responsiveness of the busy dialog with a
multi-threading approach in which the dialog window is created in a
seperate thread which then runs a message pump, but understand that
this is not straightforward.  I've had a good look through this forums
archives and understand the "thread-unsafeness" of the VCL heirachy,
the mechanics of the Synchronise() method etc. etc.  (The conceptually
pure concept of shifting the file conversion routines to worker
threads is way more work and trouble than it's worth, I'm after a
quick and contained fix I can apply to the 'Busy' module.)

As I understand it I have two options, I just wanted to bounce the
problem off the group in case there was another angle I hadn't
considered.

1) Implement my dialog solely with WinAPI calls (no VCL)

2) Wrap my dialog up in a DLL 


Any other suggestions???

Thanks

Richard Lang

MAIL: richardDOTlangATtrimbleDOTcoDOTnz