Simple doubt about modal dialogs (they block caller they do not?)

Scenario:


Class A -> need to perform about 30 cycles. Every one of these cycles should be shown at the user as soon as it completes in a window with a graph (don't mind how this graph gets done).


Class B -> is the CDialogDlg class where the graph is done. This should be a modal dialog, so I load it with

Code:

---

CDialogDlg m_dlg(this);
m_dlg.DoModal();

---

The problem is that the window with the graph (Class B) should have a button "NEXT CYCLE".
I don't like the idea of the window closing, letting class A doing its job, and then the window reappears with the next graph.


I simply don't like the idea of closing and re-opening the window. I'd prefer if the "NEXT CYCLE" button press put the user in a "Wait for completion" message or something like that without closing the window.


Any idea? Do you got anything of what I've written till now?

Create Separate thread to perform processing and wait in main thread, with

PreTranslateMessage to not block GUI updation

It's not working, I did something wrong.


I used this code:

Code:

---

m_thread= new CUIThread();
m_thread->CreateThread();

// Create mutex here
...

// block here till the dialog created by the thread isn't fully loaded
while(WaitForSingleObject(m_VisualOverrideThread->thread_synchronize_mutex, INFINITE) != WAIT_OBJECT_0) {};

---

and the CUIThread class has this code:

Code:

---

BOOL CUIThread::InitInstance()
{

        // Show window
        m_dlg = new CDlg(0, pointer_to_mutex);
        m_dlg->DoModal();

        return TRUE;
}

---

the mutex is then released into the OnInitDialog of the dialog.

But the problem is: the window won't show up.


Can someone suggest me a link to create another MFC thread with a window associated?

I basically need a window to act like a modal till the user won't press a key, then act like a non-modal.

Quote:

---

Originally Posted by pm44xl23

Code:

---

// block here till the dialog created by the thread isn't fully loaded
while(WaitForSingleObject(m_VisualOverrideThread->thread_synchronize_mutex, INFINITE) != WAIT_OBJECT_0) {};

---

---

That seems like an infinite loop to me. Edit: A possible infinite loop at least. ;)

Quote:

---

Can someone suggest me a link to create another MFC thread with a window associated?

---

http://www.codeguru.com/forum/showthread.php?t=312452

Quote:

---

I basically need a window to act like a modal till the user won't press a key, then act like a non-modal.

---

If you want your application to block while it is calculating then don't use a worker thread. That's generally not advised, though. From Vista your application can even get frozen by the OS when it is non-responsive too long. It's better to just show some message to the user that the application is calculating, but keep it responsive in the mean time.

Here's the approach I would take.

Dialog B becomes a property sheet class that holds pages that represent each cycle. Don't worry about having to create a bunch of separate CPropertyPage derived classes, you can just create one and reuse it for each page.

Dialog A now creates a modeless instance of the propertysheet class. Modeless is used here because your requirements said that you need to update some visual elements in dialog A as each cycle completes. To do this, the active propertypage will send a user defined message to Dialog A. Dialog A will handle the message and update the appropriate ui elements.

Within the property page (the one that gets reused for each cycle) I would still perform the calculation within a thread. Some folks feel like if you have to wait on something in the UI, then there's no reason to use a separate thread. The point is is that if you have to wait in the main thread the parallel nature of a worker thread provides no benefit. I respectfully disagree.

In general it's good practice to provide a separation between the UI and business layer. It's also good practice to allow the user to remain in control and be able to cancel worker operations.

If you try to fullfill both these in the UI thread, you end up with tightly coupled code. For somewhat longer running calculations (> 1 or 2secs), you'll need to ensure that the UI doesn't freeze up so you'll have to pump messages in the middle of the calculation code. This sort of tight coupling is exactly what we are trying to avoid.

Reasons to use a worker thread is to provide loose coupling between the UI and business code. The typical way to do this is the UI thread creates a worker thread and passes the data to be worked on to the thread. For thread control, event objects can be used. For progress during the worker operation, a user defined message can be sent to the UI window(s).

The coupling between the UI and worker thread is kept to a minimum: about the only thing the worker thread needs is an hWnd to the window it needs to send any progress messages to. The waiting in the UI can be easily accomplish by disabling/enabling controls. For example, in this case, the "Next cycle" button can be disabled while the worker thread is calculating. After the worker thread has finished the work, it sends a CALC_COMPLETED user defined message, and then exits. The current page handled the message and reenables the Next Cycle button (and sends another user defined message to the main dialog).