General and Desktop

@Chris-Kawa thanks, that is even more elegant!! Just was wondering my solution is bad, because, what happens if i had more than one QFrame?.. or more than one button?.. the style will be changed for all of them... but identifying as you said then that problem will gone..

TLDR for googlers thx to Chris Kawa & JHilk: QVector<QString> awesomeVector; for (QString& string : awesomeVector) // deep copy if container is shared & reference count greater than 1, otherwise no deep copy const QVector<QString> awesomeVector; for (const QString& string : awesomeVector) // no deep copy QVector<QString> awesomeVector; for (const QString& string : qAsConst(awesomeVector)) // no deep copy

@Cesar Since you're using -debug-and-release both configurations are built, but you need to install them separately, so after you build do cmake --install . cmake --install . --config Debug the first one installs the Release config and the other one Debug. With that you shouldn't add two versions in the VS tools dialog. It's the same build and you switch between them with the configuration switch combo box.

@1XU7 said in layout set and widget as parent...: i tought by setting wdg as parent to button, and wdg has lay as layout, the layout would add button automatically... No and I don't see any evidence that a QObject-based parent-child relationship should have something to do with a layout. The other way round is correct - when you add a widget to another widgets layout then the other widget is becoming the parent of the child because otherwise parent-child stuff like e.g. event propagation would not work. So no, no need to set a parent in your code but it will also not hurt and makes it more obvious what you're trying to do.

Hi, You can use the LIMIT clause in your query depending on what you want to achieve. It can help for doing paging.

From the last code you have shown it looks like you don't want the regular undo/redo feature. Here is the regular idea of a QUndoCommand: When the user does an action you create a new command and push it onto the QUndoStack. Normally, the actions are undone through the undo stack. This might be through a shortcut (Ctrl+Z) or the menu. The QUndoCommand has both a redo() and an undo() function. When you push the command on the stack it will execute the redo function. When you undo the stack, you don't create a new command, but the undo stack will just execute the undo function of the same command that is already stored on the stack. And the stack does not drop your command immediately, so you could actually undo the undo operation (i.e. the redo). It allows you to redo the exact same command which is stored on the undo stack. I am not sure if your double click action would fit right in to the undo/redo functionality. It is probably not what a user expects. The only way this could work out is if you have both an expand undo command and a collapse undo command. So, if you double click to expand you push the expand undo command to the undo stack. The use could now undo to collapse again and after redo to expand again. However, if the user double clicks again you would push a collapse undo command on the undo stack. What that means is that your implementation for redo() in your expand undo command is the same as the undo() in your collapse undo command and vice versa. Before you write any undo commands you should figure out what to do when double clicking to expand or collapse. If this code works without first creating an undo command you can then put the code for expansion into the redo() function and the code for collapse into the undo() function of your expand undo command (and the other way around for your collapse command -- you might want to have ExpandCollapseUndoCommand which receives an additional boolean (or better an enum) to choose between expansion or collapse). If you can't figure out what to do without the undo command you will not be able to write the undo command.

Just to close this out - problem solved. The issue was not the MD5 hash calculation. It was the fact that Qt4 and Qt5 differ when using this constructor QByteArray ba(QString &); The conversion did not produce the same array - which was used to calculate the hash. This gives the appearance of "working" if the QString is Ascii or straight conversion to Latin1. The problem manifested when the QString was a unicode string for a non-Latin base language! Solution: QByteArray ba(QString value.toUtf()) - before calculating/verifying the hash! Thanks for all the suggestions!

@ChrisW67 good point on setting it once. I posted on the pyqtgraph google group, thanks for the suggestion!

For anyone else encountering this issue, what was required in the CMakeLists.txt was qt_import_plugins(application-gui INCLUDE Qt::QGtk3ThemePlugin) as well as making sure the following packages were installed when building the static libraries and making sure to do a completely clean build after installing them. sudo apt-get install libgtk-3-dev libglib2.0-dev

@Michael-Lehn said in Change how selected a QGraphicsItem object is displayed: My implementation works but I wonder whether it is the "right thing" ... Should be fine since you only change the style. The selection behavior should not be affected

You can set the focus with QWidget::setFocus() but why do you want to confuse the user?

@blane245 Thanks, lost a lot of time without figuring this out and then I found this useful thread.

Quite the contrary, proper role handling is paramount to have a correctly working model view implementation.

@Captain-Haddock self.setStyleSheet("MyDialog { background-color:#4C535D; ... }") I believe should prevent that inheritance?

@Ragbot Yes, assuming what you are getting is just JSON content, see void QNetworkReply::finished(). You can also do a readAll() there to read and save reply in one call. Presumably Ok unless package data is huge. Try just moving your readReady() to that signal?

@Christian-Ehrlicher @Christian-Ehrlicher Thank you. Such an embarrasingly simple mistake.

@Oodini Seems you want to reinvent the wheel :) class LoggingDialog: public QDialog { Q_OBJECT public: LoggingDialog() : QDialog(nullptr) { setWindowTitle("Logging"); auto vLayout= new QVBoxLayout(this); vLayout->setSpacing(14); combo=new QComboBox; vLayout->addWidget(combo); auto label=new QLabel("Enter your password"); vLayout->addWidget(label,0,Qt::AlignCenter); edit=new QLineEdit; edit->setTextMargins(2,0,2,0); edit->setEchoMode(QLineEdit::Password); vLayout->addWidget(edit); auto button=new QPushButton("OK"); //button->setEnabled(false); vLayout->addWidget(button,0,Qt::AlignCenter); connect(button, &QPushButton::clicked, this,[this]() { bool ok=false; emit checkPassword(currentName(),edit->text(),ok); if(ok) { accept(); } else { // wrong password QMessageBox msgBox(this); msgBox.setWindowModality(Qt::WindowModal); msgBox.setText("Invalid password !"); msgBox.setStandardButtons(QMessageBox::Retry | QMessageBox::Cancel); if(msgBox.exec()==QMessageBox::Cancel) reject(); } }); } QString currentName() { return combo->currentText(); } signals: void checkPassword(const QString& name, const QString &pass,bool& ok); private: QComboBox* combo; QLineEdit* edit; }; ... LoggingDialog dialog; QObject::connect(&dialog,&LoggingDialog::checkPassword,[](const QString& name, const QString &pass,bool& ok) { ok=false; // msgbox will show up }); if(dialog.exec()==QDialog::Accepted) { qDebug()<<"Password correct for"<<dialog.currentName(); } else { qDebug()<<"operation cancelled"; } [image: Password.png]

Hey Simon, Yes, any simple scenario like CreateFile -> CloseHandle or QFile.open() -> QFile.close() works as expected, and the file is opened, then closed. When I mix them together I never see the close happening irrespective of QFileDevice flags provided and if CloseHandle() or QFile.close() is called. QFile.isOpened() returns false after the fact though.

@jsulm I finally found my mistake, I'm missing the install qtspeech5-flite-plugin Thank you