General and Desktop

@SGaist you can use dynamic properties to keep everything in one place Didn't understand what you meant use a QMap to store the reply specific data that you will then grab in your lambda Could you provide a minimal sample code on how to do that

That's interesting that the setBackground(QBrush()) works for you. Looking at the code, QGraphicsScene::drawBackground() doesn't do anything when the background brush is Qt::NoBrush (which is what QBrush() is). Not sure what Q_D(QGraphicsScene) does; it's called at the beginning of many QGraphicsScene methods but I didn't see where it was defined. This is the code from Qt 5.12: void QGraphicsScene::drawBackground(QPainter *painter, const QRectF &rect) { Q_D(QGraphicsScene); if (d->backgroundBrush.style() != Qt::NoBrush) { if (d->painterStateProtection) painter->save(); painter->setBrushOrigin(0, 0); painter->fillRect(rect, backgroundBrush()); if (d->painterStateProtection) painter->restore(); } }

@raven-worx Thank you once again, this solution was spot on :-) Kind regards, Yina

SIGNAL(currentItemChanged(QListWidgetItem * current, QListWidgetItem * previous)) This code is not valid. You don't pass parameter names to SIGNAL macro, only the types. It should be SIGNAL(currentItemChanged(QListWidgetItem*, QListWidgetItem*)) how does SIGNAL process (...) parameters SIGNAL macro just stringifies the function name and parameters, so if you have a void something(int) signal it creates a string in a unified format like "2something(int)" (just an example, the actual format of that string is internal and not important to you). Same goes for the SLOT macro. Internally connect uses these strings to match function signatures. If, for educational reasons, you're curious what the format of that string is you can just write it out: qDebug() << SIGNAL(currentItemChanged(QListWidgetItem*, QListWidgetItem*)); how does SIGNAL (...) acquire parameters and HOW to pass them to slot . The code that emits that signal just passes them, so for example some function in the QListWidget will have: void QListWidget::something() { ... QListWidgetItem* current = ...; QListWidgetItem* previous = ...; emit currentItemChanged(current, previous); ... } Emiting a signal like emit someSignal(42) is conceptually something like this (in pseudo code). This is what moc generates as the function body of that signal: void someSignal(int param) { foreach (connected_slots) { if (stringified_signature_of_signal matches stringified_signature_of_slot) slot(param); } } can I envision these parameters as some kind of global variable ? I'm not sure what you mean. You're getting them in the slot so you can see them there. If you want to inspect them before the signal is emitted just set a breakpoint where the signal is emitted. In your example you ignore signal parameters. If you want to inspect them in the slot you need to change the slot signature to receive them: void testSlot(QListWidgetItem * current, QListWidgetItem * previous) and change your connect statement accordingly to use SLOT(testSlot(QListWidgetItem*, QListWidgetItem*))

yes, i understood thanks

@mrjj Thanks, it seems like odd behaviour. So, it uses its native palette, i.e. the palette set either directly or inherited from its parent. I am able to change the colour now, but I am using a C-Style cast, and that's why I am not sure if I should do it. Here is my solution: void GuiStyle::drawPrimitive(QStyle::PrimitiveElement element, const QStyleOption* option, QPainter* painter, const QWidget* widget) const { if(vars[id].customTheme) { if(element == QStyle::PE_PanelLineEdit) { const QStyleOptionFrame* comboOption = qstyleoption_cast<const QStyleOptionFrame*>(option); QStyleOptionFrame newComboOption = *comboOption; newComboOption.palette.setBrush(QPalette::Base, Qt::red); // I am using C-Style cast to get the widget in a non-const pointer and then it's palette again the same way QLineEdit* lineEditPtr = (QLineEdit*)widget; QPalette pal = (QPalette)lineEditPtr->palette(); pal.setColor(QPalette::Text, Qt::green); lineEditPtr->setPalette(pal); QProxyStyle::drawPrimitive(element, &newComboOption, painter, widget); } } else { QProxyStyle::drawPrimitive(element, option, painter, widget); } }

@Mc6bullet Are these entries you have created yourself, or something from Qt? If from Qt then presumably something needs configuring to use Linux commands instead. If your own: in a Windows Command Prompt type xcopy /? to understand its existing usage. Then translate to the equivalent in Linux. I would suggest you might need to use rcp, or perhaps cp -r will suffice. Use man rcp or man cp to see their usages.

@Christian-Ehrlicher Sorry for trying that.

@jsulm With resource file it is working thanks.

@jsulm Is there any logger system is there like log4j in qt whose log i can on and off in file as per my need ?

@ekato993 said in get the return value of the emitted signal: I know about lambdas but how to pass the string? Perhaps you are aware about lambdas but that is not the question here. You have to learn signals/slots usage, because it is a very important concept in Qt world. So if you want to build applications with Qt, take time to learn: what QObject are => https://doc.qt.io/qt-5/object.html what QObject parent <=> child relation chip => https://doc.qt.io/qt-5/objecttrees.html how signals/slots works => https://doc.qt.io/qt-5/signalsandslots.html Those are the minimum to be comfortable with Qt development. This will save you many hours of frustration and headaches! It is up to you to learn, the documentation is freely available.

Not question related, but this line: @SPlatten said in Windows 10 QDir::separator: if ( strPath.endsWith(chSeparator) != true ) will be better in this way: if ( !strPath.endsWith(chSeparator) )

@kenchan What library are you trying to load?

@thewiggin said in Connect signals and slots of a class from another class: Here's my workaround, it seems needlessly complex and has me begging the question of if its possible to connect to the slot of another class outside that class. All the declarations I can find use "this" as the third augment. Yes of course! you see "this" because normally the sender or/and the receiver is the class itself, but you can connect one or two classes that arent the classe itself! But this you already see in your last post!

@borhanreo Hi and welcome to the forums The Image didnt show up and is generally broken here. use something like postimage.org and the Direct link.

@UG-SEP Google says: https://download.qt.io/new_archive/qt/5.8/5.8.0/

@JonB said in QDocument has not expected behavior when creating elements: And in this case the setAttributeNode() docs show it returns the attribute node it is replacing, or a dummy node, and that's what you setValue() `on. Qt's stuff does work and as documented so not unexpected, just not to the chaining expectations you have have from, say, jQuery or whichever XML DOMs. You are right the QDomElement::setAttributeNode() does indeed not return a copy but a null attribute. Manual on QDomNode::insertAfter(...) states: Returns a new reference to newChild on success or a null node on failure. The DOM specification disallow inserting attribute nodes, but due to historical reasons QDom accept them nevertheless. My first interaction was the PHP XML Dom setAttribute(...) where the manual says: The new DOMAttr or false if an error occurred. Where I'm used to chain functions. Looking to the Java implementation, which I never worked with, does the same as Qt's implementation. Chaining makes it easy because local variables are superfluous in that case and for me it is more readable. Conclusion: My assumption was apparently incorrect.