I want to create a dialog in MFC that, once it shows up, it can't lose focus.
This is for blocking the user access to the main SDI window, while it is processing data. The flow is something similar to:
User triggers process
Application shows the dialog
Application starts the process function
I can't do this with a Modal dialog, because the DoModal() function doesn't return until the dialog closes, so this will never trigger the step 3.
How can this be done?
Edit
These are the functions for notifying a task start and task end:
void CmodguiApp::_notify_task_start() {
_processing_dialog->DoModal();
}
void CmodguiApp::_notify_task_end() {
_processing_dialog->EndDialog(1);
}
This is the code triggering a task process:
void trigger_task(std::function<void()> f) {
CmodguiApp::_notify_task_start();
f();
CmodguiApp::_notify_task_end();
}
Try the following approach:
Call the
_processing_dialog->DoModal();
On the Process dialog class do it wherever appropriate:
AfxGetApp()->GetMainWnd()->SendMessage(WM_YOUR_USER_MESSAGE)
On the main window class message map, add
ON_MESSAGE(WM_YOUR_USER_MESSAGE, YourUserMessageHandlerFunction)
Implement the YourUserMessageHandlerFunction(). Now you have retaken the handling at the main window.
Related
I have Main Dialog which has some buttons. Each button will generate an independent dialog as follows:
void MainDialog::onAButtonClicked()
{
Dialog *dial = new Dialog(pass some parameters);
dial->show();
}
The problem with this approach is when the user closes the Main Dialog, the running independent dialog is not closed. I don't want this issue to occur. Some solutions suggest to override closeEvent and reject, I've tried them but these require me to create *dial as a member data of Main Dialog. This works but I don't want this approach because I need to delete this dialog once the user closes the window completely. I've tried to allocate some memory using new and delete object on close or reject events but the app hangs. What is the proper approach to solve this issue?
connect(this,SIGNAL(finished(int)),dial,SLOT(close()));
or
connect(this,SIGNAL(rejected()),dial,SLOT(close()));
I am developing an application which allows multiple Modal dialogs to be opened simultaneous. I have been experiencing an issue as to whenever I close the first dialog, it closes without error and call doesn't back to the callee until I close the second dialog which is defeating the purpose what I have to achieve.
Sample code:
Class A
{
func1()
{
....
DOModal()
....//some processing
}
Class B
{
func2()
{
...
doModal()
}
}
I tried with creating a user thread and event mechanism by associating it with the dialog but what is happening is it's actually not letting me to open the another dialog until I respond. I still want the execution to happen as it is.
My application is a single threaded environment.
DoModal dialog will allow you to launch only one at a time for each thread. Instead, you can try create and show the dialog with the parameters nIDTemplate as the ID of dialog and pParentWnd as parent window. Here you will not be required to create the multiple threads.
I have a queer sort of problem. Consider the following scenario:
Main window creates a child dialog on click of some button.
Child dialog does some task in a worker thread.
An error occurs during that task causing a message box to be displayed saying something along the lines of "Yikes! Something went wrong.".
Child dialog's 'Cancel' button is clicked on causing the child dialog to be closed.
Message box is still active! Clicking on anything in the message box = crash.
Pseudocode of how things are happening: (please ignore syntactic correctness here)
MainWindowClass mainObj;
void MainWindowClass::OnSomeButtonClick()
{
SomeDialogClass someDialogObj;
someDialogObj.DoModal();
}
int MainWindowClass::doTask()
{
// Do work
if(ERROR)
{
MessageBox("Yikes! Something went wrong.", "Error", MB_OK);
return ERROR;
}
}
///////////////////////////////////////////////////////////////////
// Meanwhile, in another file,
extern MainWindowClass mainObj;
void SomeDialogClass::OnCancel()
{
// Do all cleanup and close dialog
}
int SomeDialogClass::workerThreadFunc()
{
return mainObj.doTask();
}
int SomeDialogClass::DoModal()
{
AfxBeginThread(workerThreadFunc);
// Do all other work and then wait for the worker thread
}
My question is twofold:
On cancel, is there a way to know if any message boxes/dialogs in
the same application are active?
Is my entire design wrong and should I be doing something else altogether?
I thought one of the main reasons to use a modal dialog was its ability to prevent focus from going to parent dialogs. Yet, when that error message box is shown, I can happily click on the dialog and then click on 'Cancel' and pretend that the error message box never showed.
Rather than have your worker thread bring up a modal message box, it should signal the error condition back to the UI thread. My experience of MFC and multi-threading is that having all UI handled in the same thread makes things much simpler and removes these types of error. Having two threads potentially bringing up modal dialogs at the same time is asking for trouble.
I'm kind of new at this, but my suggestions would be if the child is going to be cancelled when there is an error then destroy it before launching the error.
As far as I can tell, the SomeDialogClass is modal, then the parent launches another modal dialog, the MessageBox. Now, if SomeDialogClass was modeless then the message box would appear on top since SomeDialogClass would then be a child of the entire desktop and the sole child of MainWindowClass would be the MessageBox.
I'm under the impression that modal only prevents focus from going to things underneath the modal dialog, not what is launched on top or after it is open. I've done a modal dialog, launched a modeless from it, and could move both around the screen just fine. Additionally, I created a WM_MESSAGE from the modeless dialog back to the modal to announce when it was done so the modeless could finish.
My program use a modeless dialog to interact with the user and also has a tray icon.
A user can quit the app immediately by using the tray icon.
BOOL OnInitDialog()
{
init data...
}
void OnDestroy()
{
destroy data...
}
void OnSomeButton()
{
CFileDialog dlg;
...
dlg.DoModal(m_hWnd));
access data...
...
}
void OnMenuExit()
{
DestroyWindow();
}
The problem is that when I popup a modal dialog(OnSomeButton), and then quit using the tray icon menu, the main dialog is destroyed first, and then the modal one returns, trying to access some invalid data, causing a crash.
I know i can add some check code before accessing the data, but is there any other way?
Is there any way to ensure OnSomeButton() returns before window destroy?
You need to add your own application level code. There is no system support for this issue primarily because there can be so many pecularities that no generic approach is possible.
Yeah. When you quit from the tray menu, you can send a WM_CLOSE or similar message to your modal dialog that causes it to exit. Even if your main window is destroyed before that OnSomeButton returns you will be okay provided the remainder of that function does not access any class internals (member variables etc). You could ensure this by having the window proc of your modal dialog return an 'abort' code or something when it is closed in this way.
I am developing a project using Qt4 and I have run into a slight issue.
I am creating a modal window from the main window. I want this to disable the toolbar at the top.
I have a menu item that spawns the modal from the menu. What I want is that when the modal is spawned that menus is disabled. I have tried using the setEnabled(false) function but that doesn't reset it.
Here is the code:
void Main_Screen::Create_ViPro()
{
std::auto_ptr<ViPro_Dialog> modal(new ViPro_Dialog(this));
modal->show();
modal->exec();
}
So It is just a simple class that is triggered when a menu item is selected. I feel that the problem stems from the fact that i'm setting the parent to the main screen, however I don't know how to create a modal without a parent(it doesn't make sense to do that). Is there a way to disable the parents toolbar from the child? The only thing I have seen so far is _fileMenu->setEnabled(false);
That works as long as I don't create the modal, but as soon as that is spawned, the menu works again. I'm totally lost.
Thanks in advance
Edit as Patrice
Here is the constructor
Main_Screen::Main_Screen(QWidget* parent /*= NULL*/)
: QMainWindow(parent),
_newProj(new QAction(tr("New &ViPro"), this)),
_fileMenu(menuBar()->addMenu(tr("&File")))
{
//create slot for creating a new project
connect(_newProj.get(), SIGNAL(triggered()), this, SLOT(Create_ViPro()));
_fileMenu->addAction(_newProj.get());
//if i do this then setEnabled(false) works perfectly and i can't access the menu
Create_ViPro()
}
So the function is signaled by triggering the newproject action. If i call the function directly from within the constructor it disables it as you stated patrice, however, if I have the function called via the trigger, it doesn't disable it. Am I handling the signal / slot mechanism wrong? Thanks again.
Another example, if I make the function create_vipro() as below
void Main_Screen::Create_ViPro()
{
_fileMenu->setEnabled(false);
}
The file menu isn't disabled when I trigger the event, so it must have nothing to do with the modal itself, but instead how signals are handled.
Since child is a modal dialog main screen can't react to event. But you can disable the toolbar (or menubar) before creating the modal dialog and enable it as soon as you leave the exec function:
void Main_Screen::Create_ViPro()
{
_fileMenu->setEnabled(false);
std::auto_ptr<ViPro_Dialog> modal(new ViPro_Dialog(this));
modal->show();
modal->exec(); // Will stay here until you close the modal dialog
_fileMenu->setEnabled(true);
}
if ViPro_Dialog is really a modal dialog it will works.
Another thing, since ViPro_Dialog is modal you can declare it locally without using auto_ptr:
void Main_Screen::Create_ViPro()
{
_fileMenu->setEnabled(false);
ViPro_Dialog modal(this);
modal.show();
modal.exec(); // Will stay here until you close the modal dialog
_fileMenu->setEnabled(true);
}
EDIT:
I guess (I can't test at work) that you can't enable/disable menu when it is executing a QAction. Signal is calling slots sequentially so QAction is busy when you try to disable the menu.
Try this:
In Main Screen, create a slot with one boolean parameter that enable/disable menubar. Just call the setEnabled function
In ViPro_Dialog, emit a signal with a boolean parameter (false at startup, true at validation)
In Create_ViPro, once dialog created, connect the new signal with the slot, exec dialog and don't forget to disconnect slot from signal:
void Main_Screen::Create_ViPro()
{
ViPro_Dialog modal(this);
// Connect signal/slot
modal.show();
modal.exec(); // Will stay here until you close the modal dialog
// Disconnect signal/slot
}
This can achieve what you want
EDIT2
You are doing a mistake when using modal dialog. There's a conflict between show() and exec(). When you are displaying modal dialog you don't need to disable other windows: it's automatically done by modal status of the dialog. There are many modal depth: http://qt-project.org/doc/qt-4.8/qt.html#WindowModality-enum. So your code should be:
void Main_Screen::Create_ViPro()
{
ViPro_Dialog modal(this);
// modal.setWindowModality(Qt::WindowModal); // Uncomment this line if you want to only disable parent
modal.exec();
}
Read this for more detail: http://qt-project.org/doc/qt-4.8/QDialog.html#details.
Using exec() doesn't just create a modal dialog, it also suspends most of the regular event handling, and only handles events in the dialog that is in exec(). This may include some UI updates (like the transitions from enabled to disabled), but I'm not positive. A better way to handle this might be to explicitly set the dialog modal, but allow the regular event loop to continue, something like this:
void Main_Screen::Create_ViPro()
{
ViPro_Dialog* modal = new ViPro_Dialog(this);
modal->setModal(true);
modal->show();
}
That code will still not visually disable the toolbar or menubar, but they should be unresponsive. To disable them, you could try combining this with Patrice Bernassola's answer.