How to simulate the cancel button pressing for QFileDialog?
Searching doesn't help much here as most threads (like this one) are talking about simulating key pressing for QT application, not particularly for a QFileDialog.
P.S.: I want to do this because currently I am using a library created by others, the code somehow depend on the QFileDialog to open. It is becoming very annoying if needing user intersection each time by manually pressing the cancel button.
Any help is appreciated.
I assume the library uses QFileDialog as shown in the documentation:
QFileDialog dialog(this);
dialog.setFileMode(QFileDialog::AnyFile);
QStringList fileNames;
if (dialog.exec()) {
fileNames = dialog.selectedFiles();
}
In that case you can just hide it. It causes exec() to return QDialog::Rejected immediately:
fileDialog->hide();
Related
I am trying to fix a bug in a Qt app which I did not write. The window changes the background color of the entire window to red and puts up some buttons, dialog boxes, etc. When the escape key is pushed, the boxes and buttons go away, leaving an empty red screen. The Cancel button does the right thing in returning to the previous window. I think I need to somehow be notified of when the escape key is pushed, and then call the same function as the cancel pushbutton does. Hopefully, I can limit the scope of this special action to when the problem window is up. I am an experienced programmer but a complete Qt newbie. This app is purely C++. To my knowledge, it does not appear to use any QML. I am still searching through the Qt online documentation, but any suggestions / examples are appreciated.
This depends a lot on your specific Qt version and setup of your application. That said, I'll take a shot at helping. In the class where you're trying to intercept the escape key press, assuming it's inheriting QObject, simply override the virtual function eventFilter. Inside your overridden instance of eventFilter, check that the QEvent type is a QEvent::KeyPress, and then check whether the key of that KeyPress is the escape key, and handle as needed.
Be sure that you pass the event out of your function, else you'll see your overridden function eat all events. If you explicitly want the event to be "eaten", simply do not return it from your function. For specifics and examples, check out documentation of QObject::eventFilter().
My team is developing an UI for an apparatus with touch screen and we would like it to emit a sound (from a buzzer) each time the user correctly presses a button (so using the release event). Notice that I don't want to play the sound after each click on the interface, but only when the click is over a button.
We use many types of button, sometimes QPushButton and most of the times customized buttons derived from QAbstractButton. In most cases these buttons get an objectName.
So I supposed in order to do that, I would have to catch the MouseButtonRelease event and since I'm already working with a subclass of QApplication to handle excetions, I decided to do this in the notify function.
I tried, then, some methods to recognized when the MouseButtonRelease was related to a button but none of them were successfull. The best one, verifying the receiver's objectName was still not good enought not only because not all buttons had an objectName (which, of course, can be handled), but specially because not always the event was caught for buttons with names set. In other words, sometimes I would click in a button and it recognizes the event and sometimes I would click in the same button and the event is not recognized.
I did some research and another method I found was to set an event filter in the MainWindow, but not all widgets have the MainWindow as their parent which means I would have to Ctrl+c / Ctrl+V the same code time after time when I obviously want something more localized (i.e. in only one spot).
So why it happens that the notify not always handles the events? And how could I do this? Any suggestions are appreciated specially one that is less heavier then handling the events globally.
As info, the other two ways I tried to catch the events with similar or even worst results inside notify were with receiver->inherits("...") and qobject_cast< QAbstractButton* >(receiver).
I am writing a program in Qt that looks like this:
The main window is my class Window : QWidget, it has a QGridLayout containing four other widgets (Input_Menu : QWidget and Output_Menu : QWidget, and then two Canvas : QWidget)
I would like to trigger certain events when the user strikes a key. The problem is, the Window sometimes loses focus (it goes, say to Input_Menu, or maybe a button in Input_Menu...)
I have tried the following solutions, but they seem unsatisfactory (and dirty):
Give Window the focus whenever it loses it.
Tell each widget who could have the focus to trigger Window's KeyPressEvent function (or a clone of it) whenever it receives a keyboard event.
Ideally, I would like that if a widget receives an event (say a keyboard event) and doesn't know what to do with it, it should automatically call its parent's event handler. I would have hoped this to be a default feature of Qt but it doesn't look like it. On the other hand I am really confused about the whole focus thing, I don't really get what's going on. Can someone explain this to me: I have included a std::cout << "key pressed" << std::endl; in my Window::KeyPressEvent function. When I first run my program, it seems the focus is on the top QComboBox in Input_Menu: if I hit the Up/Down keys, I navigate in that box and no "key pressed" is showed in my console. If I hit most letters, nothing happens. But if I hit Left/Right keys, I do get a "key pressed" in my console!?
Thanks a lot in advance for your insights.
You can install an event filter on QApplication to filter the relevant QEvent::KeyPress events globally. From the Qt documentation:
It is also possible to filter all events for the entire application,
by installing an event filter on the QApplication or QCoreApplication
object. Such global event filters are called before the
object-specific filters. This is very powerful, but it also slows down
event delivery of every single event in the entire application; the
other techniques discussed should generally be used instead.
Besides the performance considerations, remember to check if your window currently has the focus before you filter the key event, or you might break popup dialogs or input into other windows.
Actually, I found that for keys that are modifiers (such as Shift, Control), Qt supports finding out whether they are pressed.
Eg : if(QApplication::keyboardModifiers() == Qt::ShiftModifier) ...
This is good enough.
When clicked multiple times, a qsystemtrayicon should open only once. How is it possible?
That's up to you handle how many instances of a Window are fired up. QSystemTrayIcon has nothing to do with it. You most probably are creating a widget each time the system tray icon is clicked, instead of using just one and calling QWidget::show() and QWidget::hide() respectively. That's the best shot i can take at your issue, given the thin description.
I've created a new dialog using Qt Creator (version 4.7.0) - one of the templated forms (with an OK and a Cancel button).
I want the user to enter some data on the form and then when they click OK, it saves that information. So I had a look, and saw that when the OK button is clicked, it sends and signal to the dialog's accept slot.
So I right clicked on the dialog in the design view, and selected "Go to slot...". I clicked on the "accepted" option, which dropped an on_Dialog_accepted() method into the dialogs class. However, when I run the program and open the dialog, I get an error in my console saying QMetaObject::connectSlotsByName: No matching signal for on_Dialog_accepted()
So what did I do wrong?
I've found documentation on the connectSlotsByName - but nothing about any obvious pratfalls that an inexperienced Qt-developer can get themselves into.
Right-clicking on the dialog in the design view prior to selecting "Go to slot..." made a connection from the dialog's signals to the dialog's slot, which doesn't work with QMetaObject::connectSlotsByName(), since that method searches for all child objects, but not for the object itself.
What you wanted to do actually is right-clicking on the OK button, then selecting "Go to slot..." from there. It will then create a slot with the name of your button widget, and the connection will be made correctly at run-time.
It makes no sense that QtDesigner lets you select "Go to slot..." from the Dialog. You might want to file a bug to Qt's devs for that.
It is basically just as Fred explained: you did not do anything wrong. This is a QtCreator bug. And a pretty old one for that matter. Unfortunately, even two years later nothing in that regard has changed.
The assignee of the aforementioned bug decided to sort of redirect it to this QtCore bug, which simply asks for QMetaObject::connectSlotsByName() to be changed in a way that it also processes the passed object and not only its children (thereby fixing the QtCreator issue).
I had a look at the source and submitted a trivial patch.
Update: The patch got accepted, meaning this bug is going to be fixed in Qt 5.1. Note: it is not relevant which version of QtCreator your are using but which version of Qt you link your code to.