Following on from this question, I have a menu system as follows:
MainMenu > (Load Game button clicked) > LoadGameMenu
LoadGameMenu > (Back To Main Menu button clicked) > MainMenu
LoadGameMenu > (Load button clicked) > GameScreen
However, when I click on the Load button, the MainMenu is shown instead. Here's my code:
ApplicationWindow::ApplicationWindow()
{
resize(800, 600);
stack = new QStackedWidget(this);
signalMapper = new QSignalMapper(this);
mainMenu = new MainMenu(this);
loadGameMenu = new LoadGameMenu(this);
gameScreen = new GameScreen(this);
stack->addWidget(mainMenu);
stack->addWidget(loadGameMenu);
stack->addWidget(gameScreen);
connect(mainMenu, SIGNAL(loadGameClicked()), signalMapper, SLOT(map()));
connect(loadGameMenu, SIGNAL(backToMainMenuClicked()), signalMapper, SLOT(map()));
connect(loadGameMenu, SIGNAL(loadClicked()), signalMapper, SLOT(map()));
signalMapper->setMapping(loadGameMenu, 0);
signalMapper->setMapping(mainMenu, 1);
signalMapper->setMapping(gameScreen, 2);
connect(signalMapper, SIGNAL(mapped(int)), stack, SLOT(setCurrentIndex(int)));
setCentralWidget(stack);
}
I know I'm doing something wrong with the signal mapping, but I don't know what it is.
Cheers.
1) QSignalMapper maps a QObject* sender to a (int, string, QWidget* or QObject*). Since your "load" and "return to main menu" signals are being sent from the same sender object they will be mapped the same way. The solution is to connect the clicked signal of the different buttons to the mapper directly (rather than through your LoadGameMenu object), so the sender is different.
2) Since you're using a QStackedWidget, I would strongly consider using the QWidget* mapping of QSignalMapper, and connect to QStackedWidget::setCurrentWidget. This will be easier to maintain if/when you add more menu screens, rather than trying to keep up with which int index is which widget. It also makes things more readable in your code, in my opinion.
Edit: Looks like you're not understanding the setMapping function. I'd take a look at the docs for better a better idea. What you're doing there is mapping the first argument (the sender) to a signal to be sent (the second argument). In your original code, you're mapping LoadGameMenu to 0. Any time a signal is sent to the mapper from LoadGameMenu, 0 is sent to stackedWidget::setCurrentIndex` - which is why both buttons are returning you to the same place.
QSignalMapper relies on the sender of the signal to do the mapping, and you are connecting loadGameMenu twice.
If the sender is loadGameMenu, it will always show index 0.
It'd be probably best to connect directly to the buttons inside your loadGameMenu widget.
Related
I have a dialpad with numbers 1-9 and 0, and a QLabel above it to show the numbers when clicked(same as a keypad on any phone). All are push buttons. What is the easiest way to get the QLabel to show the numbers as the push buttons are clicked?
For example, if 2 then 0 then 7 is clicked, the label would update in real time with 207. The format of the Qlabel should follow standard phone numbers, 000-000-0000. I understand how to setText for one number at a time, but they keep overriding each other.
Any help is appreciated.
Thank you in advance
What you are looking for is a QSignalMapper. It maps multiple inputs through a single interface and does the sender dispatching for you.
QSignalMapper *mapper(new QSignalMapper(parent));
for (int i=0; i<10; ++i){
QPushButton *button = some_new_button_function();
connect(button, &QPushButton::clicked, mapper, &QSignalMapper::map);
mapper->setMapping(button, i);
}
connect(mapper, QOverload<int>::of(&QSignalMapper::mapped),
[this](int i){/*here your append code*/});
The easiest is to connect the clicked signal of the buttons to a slot (possibly a lambda) that changes the text of the QLabel (using setText()). If you want to append to the current text, then just do setText(label.text() + "new text");.
You have to connect the signals clicked() emitted by each QPushButton to a slot that update the QLabel text.
A brief example
In the parent constructor:
connect(qpb1, &QPushButton::clicked, this, &MyClass::handleQLabel);
And the possible slot implementation:
void MyClass::handleQLabel()
{
QPushButton * qpb = qobject_cast<QPushButton*>(sender()); // Find the sender of the signal
if(qpb != nullptr)
this->myLabel->setText(qpb->text()); // Write anything you want in the QLabel
else
{
// Do what you want.
}
}
This will do the job.
Of course if you don't want use sender() (for multi-threading concerns for example) you can either create one slot by QPushButton and do the same number of connect (heavy and quite a dirty workaround), or create a subclass of QPushButton to add a custom signal to emit with an identifier of the QPushButton and get it with a slot for example.
I hope it can help :)
QLineEdit might better suit your needs in this case if you also want your data representation to follow phone number standard such as "000-000-0000". You can make it read-only, disable interaction flags if you like (but from UI/UX perspective it is better not to, since mostly there is no reason to disallow copying), and also you can set input mask you like. Given your current situation, you can base your needs on the following example:
// Set your format.
ui->lineEdit->setInputMask("000-000-0000");
// Make sure that your text would be in the format you like initially.
ui->lineEdit->setText("999-999-9999");
// Text will be not editable.
ui->lineEdit->setReadOnly(true);
// And here, you can use QSignalMapper as other members have suggested. Or you can just connect multiple buttons somehow. The choice is yours to make.
connect(ui->pushButton, &QPushButton::clicked, ui->lineEdit, [this]
{
// Just keep in mind taht when returning text, some of the mask elements might be here, too.
ui->lineEdit->setText(ui->lineEdit->text().replace("-", "") + "1");
});
I've found a few similar questions on this but these appear to refer to cases where a message box is used in the slot handler. In my case I am a bit stuck as I am getting the editFinished signal twice even when my slot handler is doing nothing.
For a test, I have an array of QLineEdit which use a signalMapper to connect the editingFinished() signals to a single slot. The signalMapper passes the array index so I can see where the signal came from.
eg:
testenter::testenter(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::testenter)
{
// setup the UI according to the .h file
ui->setupUi(this);
signalMapper = new QSignalMapper(this);
// init the labels and edit boxes
for (int i = 0; i < 10; i++)
{
pm_label[i] = new QLabel(ui->scrollArea);
QString text = QString("Number %1").arg(i);
pm_label[i]->setText(text);
pm_label[i]->setGeometry(10,20+i*30, 50, 20);
pm_label[i]->show();
pm_editBox[i] = new QLineEdit(ui->scrollArea);
pm_editBox[i]->setGeometry(80,20+i*30, 50, 20);
pm_editBox[i]->show();
signalMapper->setMapping(pm_editBox[i], int(i));
connect(pm_editBox[i], SIGNAL(editingFinished()), signalMapper, SLOT(map()));
}
connect(signalMapper, SIGNAL(mapped(int)), this, SLOT(data_entry(int)));
}
void testenter::data_entry(int entry)
{
//dummy
}
When run in the debugger, if I enter data into one box then either hit return or select another box with the mouse (ie change focus) , then it calls data_entry twice, the first time with index of the box that is losing focus and the 2nd time with the box which gets the focus.
So my question: Am I missing something? Is this expected behaviour or a bug?
If a bug, anyone know a way round it as I wanted to use this signal to do custom validation on data when it is entered (by either return, tab or mouse click to change focus).
First off, no this isn't expected behavior, i.e. selecting a QLineEdit should not cause it's editingFinished signal to be emitted.
There are a couple of possible things that may cause this problem:
You've accidentally connected a signal twice to a slot
The slot map() is causing the newly selected box to lose focus
In the same vain, if you're debugging and using a break point to detect when the slots are getting called you may be causing the QLineEdit to lose focus when the active application changes from your QWidget to your debugger, again causing the signal to be sent again.
If you're having problems because of a doubly connected slot, which doesn't seem to be the case because you're specifically getting a signal from two different QLineEdits, you can make sure that this isn't happening by specifying the connection type, the connect method actually has an additional optional argument at the end which allows you to change the type from a DefaultConnection to a UniqueConnection.
That being said, data validation is something that Qt has an established mechanism for, and I suggest that you use it if possible, look into extending the QValidator abstract base class Ref Doc. You then tell each of your QLineEdit's to use the same validator.
I have run into the same issue. It really does emit the signal twice, which is a known bug: https://bugreports.qt.io/browse/QTBUG-40 which however has not been addressed for a very long time.
Finally I found that the best solution in my case is to change the signal from editingFinished to returnPressed. As a side effect this behaves much more predictably from the user perspective. See also here: http://www.qtforum.org/article/33631/qlineedit-the-signal-editingfinished-is-emitted-twice.html?s=35f85b5f8ea45c828c73b2619f5750ba9c686190#post109943
The OP "found a few similar questions on this but these appear to refer to cases where a message box is used in the slot handler." Well, that is my situation also, and here is where I ended up. So, at the risk of going off topic...
In my situation, when my slot receives the editingFinished signal sent from the QLineEdit, I launch a modal QMessageBox to ask the user something. The appearance of that message box is what triggers the QLineEdit to send the second, undesirable editingFinished signal.
A post in the bug report (https://bugreports.qt.io/browse/QTBUG-40) mentioned by #V.K. offers a workaround which helped me. The following is my implementation of the workaround. I let Qt magic mojo automatically connect the QLineEdit signal to my MainWindow slot.
void MainWindow::on_textbox_editingFinished( void )
{
QLineEdit * pTextbox = qobject_cast<QLineEdit *>( QObject::sender() );
if ( !pTextbox->isModified() )
{
// Ignore undesirable signals.
return;
}
pTextbox->setModified( false );
// Do something with the text.
doSomething( pTextbox->text() );
}
void MainWindow::doSomething( QString const & text )
{
QMessageBox box( this );
box.setStandardButtons( QMessageBox::Yes | QMessageBox::No );
box.setText( "Are you sure you want to change that text value?" );
if ( box.exec() == QMessageBox::Yes )
{
// Store the text.
m_text = text;
}
}
I am populating a sytem tray icon menu (QMenu) from entries in an xml file which is read when my application starts up.
I am unsure of how to properly set up the SLOT end of the action:
QList<CMenuItem> menuItems = m_layout->getMenuItems();
QListIterator<CMenuItem> iter(menuItems);
while (iter.hasNext())
{
CMenuItem menuItem = iter.next();
QAction *action = new QAction(menuItem.qsTitle, this);
connect(action, SIGNAL(triggered()), this, SLOT(launchMenuItem()));
trayIconMenu->addAction(action);
}
How does my "launchMenuItem()" SLOT know which menu item was triggered? I can't make a SLOT for each menu item as I don't know how many items will exist until run time.
I can think of some ugly ways to do this, but I am looking for the RIGHT way.
What I usually do is to use QAction::setData(const QVariant&) to store whatever action ID I need. Then on slot side I retrieve ID with QAction::data() and behave accordingly.
Note that QVariant obviously accepts much more than basic int (which is what I use to identify actions), you can pass any QVariant-compatible info.
edit : oh! btw, this is somehow ugly because I make use of QObject::sender() to cast triggered action back. Sorry for that, but it works anyway.
I have a Qaction on a menu item for deleting selected items in one of my views. Here is how i create the action:
deleteAct = new QAction( tr("Delete Selected"), this);
deleteAct->setShortcut(QKeySequence::Delete);
connect(deleteAct, SIGNAL(triggered()), this, SLOT(deleteSelected()));
I setup a keyboard shortcut (Delete Key) which should trigger the delectAct action. It works most of the time but at some points it stops working... Does anyone know why the shortcut would stop working?
Note: the action still works if i trigger it from the menu item. Its just the shortcut that doesn't...
You need to add the action to a widget, since it's the widget that will be listening for key events.
Assuming "this" is a mainwindow, simply do
addAction(deleteAct);
Note that you can add the same action to multiple widgets (that's the whole point of the separated action concept). So it's fine to add it to the mainwindow and to a menu.
Try changing the shortcut context of the action, for example:
deleteAct->setShortcutContext(Qt::ApplicationShortcut);
The shortcut works depending on the focus of the application views.
I wanted to have shortcuts working on buttons.
In my application I changed the shortcut context of the action,
added the action to the widget
and finally to the subviews of the application.
Then the necessary signals and slots of widget an action must be connected.
const QAbstractButton*button = dynamic_cast<QAbstractButton*>(widget);
action->setShortcutContext(Qt::WidgetWithChildrenShortcut);
widget->addAction(action);
ui->textBrowser->addAction(action);
ui->treeSource->addAction(action);
if (button)
{
if (button->isCheckable())
{
action->setCheckable(true);
if (button->isChecked()) action->setChecked(true);
connect(action, SIGNAL(triggered(bool)), button, SLOT(setChecked(bool)));
connect(button, SIGNAL(clicked(bool)), action, SLOT(setChecked(bool)));
}
else
{
connect(action, SIGNAL(triggered()), button, SLOT(click()));
}
}
Without seeing the complete code, I'd hazard a guess that somewhere it gets enabled/disabled. Make sure that the shortcut is getting hit in the constructor and not 'disabled' somewhere else because of a setting perhaps.
You can use http://doc.qt.io/qt-5/qaction.html#shortcutVisibleInContextMenu-prop property since QT 5.10 for this:
deleteAct->setShortcutVisibleInContextMenu(true);
I'm writing a simplified calculator using Qt with C++, for learning purposes. Each number is a QPushButton that uses the same slot to modify the text in a lineEdit widget being used as a display.
The slot uses the sender() method to figure out which button was pressed, so the correct number would be written on the display widget.
In order to have all the buttons working, I'd have to write a connection to each one of them, kinda like this:
connect(ui->button1, SIGNAL(clicked()), this, SLOT(writeNum()));
Since they all use the same slot, the only thing that changes is the button being used, so the next sender would be ui->button2, ui->button3, and so on. My question is, is there a way to reduce the number of defined connections?
Edit: Here's a useful link discussing precisely about this problem, in detail.
If you use QtDesigner or the form editor of QtCreator you can just drag lines between the 2 and it will fill in the code for you.
You could also keep all the buttons in a list structure, but I would use a QVector not a standard array.
You might also want to reconsider using the sender() method, it violates OOP design. Instead connect all the buttons to a QSignalMapper and then connect mapped() to your text box.
You should use an int in this case to identify the button which sent the signal to your slot. Essentially you use QSignalMapper for that task:
QSignalMapper sm;
QPushButton* one = new QPushButton(this);
QPushButton* two = new QPushButton(this);
QPushButton* three = new QPushButton(this);
//and so on...
sm.setMapping(one, 1);
sm.setMapping(two, 2);
sm.setMapping(three, 3);
//and so on...
connect(one, SIGNAL(clicked()), &sm, SLOT(map()));
connect(two, SIGNAL(clicked()), &sm, SLOT(map()));
connect(three, SIGNAL(clicked()), &sm, SLOT(map()));
//and so on...
connect(&sm, SIGNAL(mapped(int)), this, SLOT(yourslothere(int)));
Note: QSignalMapper is VERY useful, keep that in mind ;)
I think you can try allocating the QPushButton in a array, something like this
QPushButton* numbers = new QPushButton[10];
And then, perform the connections using a for loop
for(size_t i = 0; i < 9; ++i)
{
connect(numbers[i],SIGNAL(clicked()),this,SLOT(writeNum()));
}
But I don't think it's worth. Explicit connection, while making the code more verbose, make the connections more clear to the reader.