As seen in the picture above..
I created a wxDialog in wxWidgets. The user can click Yes or No. Upon clicking either button a standard dialog is opened giving a simple message (either Overwrite Success, or Overwrite Cancel)
Upon the click of either Yes or No, I want the primary dialog (the larger one) to close
void OverwriteDLG::OnButton1Click(wxCommandEvent& event)
{
wxMessageBox ("Overwrite Complete","CopyMeister v1.0",wxOK);
}
The above code is the event handler of the 'Yes' button. I tried the destroy function and I tried the close function. I searched the internet thoroughly but I couldn't find much help. Sometimes the program works syntactically, but the dialog never closes.
The dialog is called OverwriteDLG
I searched the internet thoroughly but I couldn't find much help.
The page below describes the wxDialog class.
http://docs.wxwidgets.org/trunk/classwx_dialog.html
From my reading of that page, if the dialog was create as modal, then the EndModal function can be used to close the dialog, returning the user action via the return code.
for close use: this->Close(true);
Related
Fig1:
Fig2:
As in Fig1, after I clicked radio button, the radio button seems not get correctly painted, seems 50% transparent.
As in Fig2, after I move my mouse to hover the radio button again, it got correctly painted.
I have no idea about what is going on behind.
What are the possible reasons?
By the way, after I pressed a shortcut key PrtSc to get a screenshot(a freeware: Greeshot), this problem disappeared.
One hint I just found is: the dialog holding the radios were in modeless mode. The problem disappeared after I showed it as a modal dialog.
Actually, to achieve below goals, I am implementing the message pump for this dialog. Perhaps I am doing something wrong in the message pump logic. Continue to check the pump.
My Goal: user can interact with other windows while showing this dialog, one exception is: user should not be able to interact with the parent dialog of this dialog in question, so that database transaction may be issued prematurally.
I used to have a similar problem within wxWidgets. Turns out it's a long lasting bug that really never had been fixed. I now use a workaround with a simple wrapper function that 'enables' the element (places focus on it) and then 'unfocuses' it. Not sure in your current setup.
As a result, it seems I did something wrong in the message pump for the dialog in question.
I am implementing the message pump for this dialog.
To avoid user interact with the parent dialog of the dialog in question, I was ignoring message for the parent dialog and to children of parent dialog.
After I changed the above logic to below, the problem got solved.
EnableWindow(hParent, FALSE);
EnableWindow(hParent, TRUE);
So, I think I was doing something wrong in ignoring message, not sure exactly where.
I have an application in which users, upon logging in, are prompted with a modal dialog where they must choose the facility they wish to work out of. At this stage, the application looks like this:
The modal dialog is shown by calling this method:
bool __fastcall ShowFacChoiceForm()
{
TFacChoiceForm *Form = new TFacChoiceForm( Application );
bool Result = ( Form->ShowModal() == mrOk );
delete Form;
return Result;
}
In this case, TFacChoiceForm inherits from TForm so the ShowFacChoiceForm() function is calling the standard TForm.ShowModal method documented here.
The issue I am running into is that if my application loses focus, it cannot become the active window again unless the modal dialog itself is clicked. To better illustrate this, I will present the following scenario:
Lets say its Friday afternoon and I decide to goof off a bit and read some web comics. With my application open, I open up another window on top of it, like so:
Then, out of nowhere my boss comes in for a performance review, and I attempt to refocus my application by clicking somewhere on the main form. For example, at the position of this red X in the next image.
In the above image, I have clicked at the location of the red X. Now, both the form containing the web comic, and my application are inactive. Thus, my application does not come to the front of the screen.
However, if I am able to click somewhere on the modal dialog, like the red X in the following image...
...then my application comes to the front like one would expect.
To solve this, I have looked at using something like SetForegroundWindow from the Windows API, but I have not been able to find a way to trigger the event, since my main form does not fire events while I have a modal dialog open.
My question is, how can I make sure that if the user clicks anywhere on my application that it is brought to the front? Is there a property I can edit in my form to do this?
If you set modalresult to mrcancel in the ondeactivate of the modal dialog then the main form will get focus when its clicked. You can then check if the user is logged in the mousedown event of the main form and if not, show the modal dialog again.
I have a desktop windows application programmed in C++ with Qt. The application has several top - level windows which occasionally need to be closed and recreated programmatically. Also, when the user of the program clicks on the close button (the one next to the minimize and maximize buttons) the whole program is supposed to exit.
The problem I have is that in both cases the top level windows receive a closeEvent() call with a QCloseEvent object. I'd like to quit the program when I see that happen (because the user might have clicked the close button), but it's also possible that the window is closing because I'm deleting it programmatically to recreate it.
Is there a way of distinguishing between these two cases in QMainWindow::closeEvent()?
Is there a way of distinguishing between these two cases in QMainWindow::closeEvent()?
Yes: the close event triggered by the user clicking on the window's close button will be a spontaneous event, the one triggered by you calling window->close() will not. See the documentation of QEvent::spontaneous() for more information.
When you need to close your window programmatically, use deleteLater() instead of close. The window will be closed and deleted. To reopen the window you will need to create another window object.
You can also use hide() method. The window will be hidden but not destroyed. It can be shown again using show().
In both described cases the close event does not happen and closeEvent() isn't called. So when closeEvent is called, you know that the user has pressed the close button.
I have a modeless QDialog box that popup on errors/warning in my Qt application, I want to force the user to only focus on that dialog box and not click anything in the application until they clicked Ok on the dialog box.
I need the dialog box to remain modeless. A solution like hiding the main window or covering it up is not acceptable.
At the moment I'm using setModal(true); to solve my problem. But I think this method might be stopping the main application from executing.
From the documentation:
If you use show() and setModal(true) together to perform a long
operation, you must call QApplication::processEvents() periodically
during processing to enable the user to interact with the dialog.
Instead of using a QDialog box, try using qDebug statements in your code or a log file using qInstallMsgHandler.
You could also show a QTextEdit and post your log/error messages there in real time, too.
http://qt-project.org/doc/qt-4.8/debug.html
http://qt-project.org/doc/qt-4.8/qdebug.html#details
http://qt-project.org/doc/qt-4.8/qtglobal.html#qInstallMsgHandler
http://qt-project.org/doc/qt-4.8/qtextedit.html#details
If you still really want to debug using a QDialog box for errors, in a pseudo modal dialog but not modal dialog, you could try using eventFilters to prevent mouse and keyboard events from arriving at any other window, but it would be tricky to allow the exception to end up only at QDialog, but it is do-able.
You could also go to the one or two widgets that accept mouse and keyboard input, and ignore the input if the a QDialogBox is visible. But both of these ways of showing an error, but limiting input without making it Modal is really hacky, and would probably be error prone.
In my QT C++ application i call a QML ModalDialog with 2 buttons (OK/CANCEL), which displays correctly on screen and so, no problem there.
However i'm struggling to find a way to retrieve in my QT C++ application which button was pressed.
I'm unable to somehow "freeze" when i call the QML ModalDialog, to wait there until the user press OK Button or Cancel Button
What i see is that application calls the QML ModalDialog, and immediately exit that part and continue.
QMetaObject::invokeMethod can call a QML function and have a return value, but it just doesn't wait for the user press one of the buttons, it just exits immediately, so no use.
I want to use this QML ModalDialog in several places of my application (the QML modal
dialog can have different text passed from my QT C++ application), so i was looking to a generic solution for this.
Basically and generic speaking i'm looking for something like this:
C/C++
return_value = QML_Modal_Dialog(....)
Can someone point me in the right direction? Thanks
QML modal dialog comes with two signals 'accepted' and 'cancelled'. If you provide handlers for these two signals in your code, you would be able to know which button got pressed.
You can refer to the below for reference.
Modal Dialog Ref 1
Modal Dialog Ref 2
Hope this helps!
Despite that the question is too old maybe my answer will help someone else.
I faced the same problem with Dialogs in QML. You think about it in imperative way, while QML is a declarative language that doesn't allow you to stop the flow of program and wait for the user's choice.
As Purnima suggested you should use signal handlers (you can find the list of them for Qt 5.6 here). Move some of your app's logic to the signal
handlers.
For example - if your function a() is executed based on the user's choice in dialog you should instead call it inside the dialog in its signal handlers (e.g. onAccepted or onRejected) with two different parameters based on the type of signal handler. Think about it as splitting the flow in two streams.