Tengo una gran aplicación basada en MFC que incluye algunas tareas potencialmente muy lentas en el hilo principal. Esto puede dar la apariencia de que la aplicación se ha colgado cuando en realidad está trabajando en una tarea larga. Desde el punto de vista de la usabilidad, me gustaría ofrecerle al usuario más comentarios sobre el progreso y tener la opción de abortar la tarea de una manera limpia. Si bien dividir las tareas largas en hilos separados sería una mejor solución a largo plazo, estoy pensando que una solución pragmática a corto plazo es crear un nuevo hilo GUI encapsulado en su propio objeto completo con un diálogo que incluya la barra de progreso y el botón de cancelación, usado en una de manera similar a un objeto CWait. El hilo principal supervisa el estado de cancelación a través de un método IsCancelled, y finaliza a través de un lanzamiento cuando sea necesario.

¿Es este un enfoque razonable, y si es así, ya hay algún código MFC que puedo usar, o debo hacerlo yo mismo? El primer boceto se ve así

class CProgressThread : public CWinThread
{
public:
    CProgressThread(int ProgressMax);      
    ~CProgressThread()
    void SetProgress(int Progress);
    BOOL IsCancelled();
private:
   CProgressDialog  *theDialog;
}

void MySlowTask()
{
   CProgressThread PT(MaxProgress);
   try
   {
       {
           {  // deep in the depths of my slow task
              PT.SetProgress(Progress);
              if (PT.IsCancelled())
                 throw new CUserHasHadEnough; 
           }
        }
    }
    catch (CUserHasHadEnough *pUserHasHadEnough)
    {
        // Clean-up
    }
}    

Como regla general, tiendo a tener un subproceso de la GUI y muchos subprocesos de trabajo, pero este enfoque posiblemente podría ahorrarme un montón de refactorización y pruebas. ¿Algún peligro potencial serio?