Hi Yves M & Andreas

Thank you for your suggestions. Yes, from the three examples I do also prefer the second one. But I think it still has some drawbacks:

1) The progress dialog is not modal. After the command handler creates the thread and progress dialog, all other commands have to be disabled. For example, in a frame Window offering 100 Functions, Toolbars etc., all these GUI elements must be disabled (even this is quite simple through the Update-messages). I would not have to worry about this if the progress dialog were just modal.
Is there a way to first create the dialog, then start the thread and make the dialog modal afterwards? without the pitfall that the thread might end before the main thread tries to make the progress dialog modal...

2) The code to start the thread is in a command-handler. The only clean way around this is as far as I see to derive an OS-specific class of the "thread"-class that handles the thread start and creates the progress dialog (on use OS-independent GUI/Thread elements, thank you Andreas). Clean, but not my dream

3) To enable the "break" command, the thread function have to somehow "ask" the dialog whether break was pressed, since the dialog can not notify the (non-"UI") thread. I think this is only possible by using a SendMessage to the dialog (from the OS-specific Progress class) and check the result. This would - as I believe - somewhat unnecessarily slow down the thread. It would be easier if the dialog would know which e.g. boolean variable to flag if a break occurs and the thread would just check this bool.
By typing this, I get the idea to provide the dialog at the thread start with such an address, maybe this would be a solution?

I'm just thinking about some possible design solutions, because I've recently tried some approaches and was not completely satisfied with the design (although it all works seamlessly).

Thanks for the discussion; please let me know if you have any more ideas.

Oliver.

PS: Sorry, Andreas, for posting in the wrong place!