Re: How to avoid the resemblance of class hierarchies?
- From: Matthias Kaeppler <noreply@xxxxxxxxxxxxxxx>
- Date: Sun, 18 Sep 2005 19:43:44 +0200
Dmitry A. Kazakov wrote:
The dialog window does, since it's the object monitoring thread progress. It fires a SignalThreadCompleted signal when work is done.
It is the source of your problem. The purpose of a dialog window is to visualize the state not to fire any actions.
Yes. That was one point I mentioned in my initial post which I am not happy with.
I'm not waiting anywhere for results. I trigger a task, which runs in an own thread from there on. Meanwhile, the application can do other stuff. When the task has finished, the TaskManager cleans up.
I /need/ this sort of functionality, because you can e.g. click a cancel button to cancel a task. So I need to have a handle to a task as long it is running.
See above. The indicator object here is the dialog window. A keyboard event activates the monitor's operation with parameter the dialog window. During its execution the operation goes through the check points which move the progress bar. Upon completion it closes the dialog box. When "cancel" is hit, the indicator sets a flag and at the next check the operation aborts itself, and again closes the dialog box.
However, the problem is not to close the dialog window but to cancel the thread. This is only possible if I can call a cancel() function on the task object. And therefor I need a handle to that task object.
Why would I want to keep the objects any longer?
Because starting and stopping threads is expensive. Then to determine the scopes of such highly dynamic objects might be difficult as your design attempt shows. So instead of piling classes on classes, it is clearer to make the asynchronous operations serviced by one or two monitors existing throughout the application's life.
Okay, I will look into that. Thanks for your input.
-- Matthias Kaeppler | Tel: +49 631 3405805 Gerhart-Hauptmann-Str. 16a | Mob: +49 176 20108693 D-67663 Kaiserslautern | E-Mail: matthias at finitestate dot org .
- Follow-Ups:
- Re: How to avoid the resemblance of class hierarchies?
- From: Dmitry A. Kazakov
- Re: How to avoid the resemblance of class hierarchies?
- References:
- How to avoid the resemblance of class hierarchies?
- From: Matthias Kaeppler
- Re: How to avoid the resemblance of class hierarchies?
- From: Dmitry A. Kazakov
- Re: How to avoid the resemblance of class hierarchies?
- From: Matthias Kaeppler
- Re: How to avoid the resemblance of class hierarchies?
- From: Dmitry A. Kazakov
- Re: How to avoid the resemblance of class hierarchies?
- From: Matthias Kaeppler
- Re: How to avoid the resemblance of class hierarchies?
- From: Dmitry A. Kazakov
- How to avoid the resemblance of class hierarchies?
- Prev by Date: Re: How to avoid the resemblance of class hierarchies?
- Next by Date: Comparing design by contract with defensive development
- Previous by thread: Re: How to avoid the resemblance of class hierarchies?
- Next by thread: Re: How to avoid the resemblance of class hierarchies?
- Index(es):
Relevant Pages
|