@hskoglund said in QObject::connect: Cannot queue arguments of type 'QTextCursor':

Thanks for the clarification, it makes sense., i.e. the detection is not "shaky" it's impossible to do!

Exactly!

I should have a coffee and study the source code for how that detection is done when signals are emitted across threads.

Coffee sounds nice, I'm now envious ... ;)
You can look here about the second part:
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject.cpp.html#_ZN11QMetaObject8activateEP7QObjectiiPPv

And, this "problem" with connecting to lambdas across threads should be documented better I think.

Perhaps you're right, but I'm too lazy to check what it really says in the docs ... :p
However I think it's documented, probably more emphasis can be put though.

@lansing
Pro Tip. ;)

If you right click your custom class name

You can easy see and insert functions from base

I may have misunderstood the case that doesn’t work.

Can you maybe do a small picture with the setup ?

@TMJJ

I hope you are not going to interpret the output of candump in your application to receive CAN frames!

SocketCAN provides a userspace API which can be perfectly used from C/C++ programs.

As SocketCAN is open source, there are lots of examples how to do this, like the SocketCAN plugin of QtSerialBus or the source code of candump.

Regards

great! That works. With that I can spare the toggle functions at all.
Thanks!

as it already suggested by other in the group, please go through signals/slots. Try few examples with how signals/slots work. This should give good info to achieve your use case.

@Kalado said in Connect() uses wrong emitter object.:

Look at some code:

//A.h class task2 : public QWidget { Q_OBJECT public: task2(QWidget *parent = 0); ~task2(); protected: void mousePressEvent(QMouseEvent *event) override; signals: void myWidgetClicked(); //A.cpp void A::mousePressEvent(QMouseEvent *event){ /// use the respective classname emit myWidgetClicked(); }

If ur using Classname as task2 , use

void task2::mousePressEvent(QMouseEvent *event){ emit myWidgetClicked(); }

Thanks,

Adding the QObject constructor to my class's constructor and adding the pointer-to-member syntax suggested by Kshegunov fixed the issue.

Thanks guys and good day.

Yep, it works.
Thanks :)

But why use QLineEdit if you are only manipulating numbers ? That makes the code uselessly complicated.

Oh well, I see http://doc.qt.io/qt-5/qspinbox.html

Signals void valueChanged(int i) void valueChanged(const QString &text)

<--rtfm! Its now clear to me :)

thanks for the enlightening!

@diverger As @micland already explained this does not have anything to do with Qt. It is a general problem with multi-threading: if you call a method from an object which leaves in another thread then you have to make sure this does not cause any problems.

@jsulm Thanks, I'll give it a try.

You don't need multiple timers, just one that's not single shot and that you stop once all rows have been filled

hi
"
When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. Execution of the code following the emit statement will occur once all slots have returned. The situation is slightly different when using queued connections; in such a case, the code following the emit keyword will continue immediately, and the slots will be executed later."

http://doc.qt.io/qt-5.5/signalsandslots.html

@Lorence
When a signal is emitted that is connected to a slot through a queued connection, the actual invocation is deferred - an event is put into the event queue that belongs to the thread the receiver object lives in for later processing. This is why when you have a multithreaded application the slot is executed in the thread where the receiver lives in, and not in the thread where the actual signal was emitted.

Here in the documentation is a more complete discussion.

@Lorence said:

Hi when you add "xxxx" to a qlistwidget
you are adding a QListWidgetItem.

While you can subclass QListWidgetItem and make your own
that has signals, it would not do you so much good as

it would never never emit such signal unless you also made it do
so when something happen to it. (overriding some of its functions)

So It all depends what you are trying to do.
If you just want to know its no 1,2,3 etc, even if moved
then
you can insert that info into the QListWidgetItem using the
void QListWidgetItem::setData(int role, const QVariant & value)

something like
QListWidgetItem * item=new QListWidgetItem("item1") ;
item->setData(Qt::UserRole, 1); // or 2 for item 2 etc
list->addItem(item)

then you can always know which is which even if rearranged.
see here for how to take index out also
http://stackoverflow.com/questions/7136818/can-i-store-some-user-data-in-every-item-of-a-qlistwidget

@TheBadger
I tried to investigate the error, and i found where it is coming from
its from this line
playList.emplace_back(ui->song->text().toStdString());
which is written before the connect() in the code

@mrmorph
well you are NOT the first to not see it.

@Chris-Kawa
my sender and receiver is in different thread.
I see! you hit all the bullseye!
THanks guys!

and i now understand the Qt::BlockingQueuedConnection

Both your classes need to inherit from QObject for the signal/slot mechanism to work.

Code blocks are either preceded by 4 spaces (good for one liners):

int variable;

or they can be enclosed by `` ` (triple back ticks, good for inline elements and longer blocks):

#include <iostream> int main (int argc, char * argv[]) { std::cout << "Hello, World!\n"; }

Google Markdown syntax for some more markup details.

There's no multi-threading involved here whatsoever. All code here runs in a single thread (unless the timer object and "this" actually live in different threads).

There's an event loop running in your app and timer events are just the same as any other. They get put in a queue and processed one after another.
The above will basically mean that your slot is run every time Qt processes messages. It can have very bad influence on your app responsiveness if what you do in the slot is heavy.

The most obvious question is: if you want a thread why not use an actual QThread instead of emulating it like that?

@errolflynn You should write self.button1.clicked.connect(ft_handler) - this will register the function ft_handler as a slot for the clicked signal. On http://doc.qt.io/qt-5/qabstractbutton.html you see that the signature of that signal is void clicked(bool checked). In other words, when the signal is activated, your handler is called as ft_handler(checked) where checked is either True or False. Per the signature of the clicked signal, this is the only information you will get out of the signal.

If you want to pass additional parameters, you indeed will need to create a separate function that encodes those extra parameters and passes them to the handler. In Python it makes a lot of sense to use a lambda for it, for instance:
self.button1.clicked.connect(lambda checked: fct_handler(par1, par2, par3, checked))

Hope this helps

@Stoyan
error: passing 'const Operation' as 'this' argument of 'int Operation::setAttribute(QString, QString)' discards qualifiers [-fpermissive]
operations.at(i).setAttribute(Aname,Value);

Не мога да разбера защо се получава това съобщение в Task класа, опитвайки се да извикам метода SetAttribute за операция във вектора.
Const Operation не знам откъде идва вътре в тази функция конкретно, след като подавам само id-то на операцията.
Подобна е грешката и при Task сетване на атрибут:
scheduledtopservice\scheduler.cpp:31: error: passing 'const Task' as 'this' argument of 'int Task::setAttribute(QString, QString)' discards qualifiers [-fpermissive]
tasks.at(k).setAttribute("state","running");

ПП:
Успях да го реша проблема. Разбрах че .at() връща const обект, затова използвах [i] за индекс.

task.cpp:17: warning: base class 'class BaseObject' should be explicitly initialized in the copy constructor [-Wextra]
Task::Task(const Task &obj)
Това как мога да го оправя, четох че създавало още 1 копие на BaseObject така. Но не е като експлицитния конструктор сякаш : BaseObject ( const BaseObject &obj) ако долепя до Copy конструктора на Task. Не съм сигурен, но май просто като сложих : BaseObject() и се изчисти предупреждението. Така ли трябвa да бъде ?

@SGaist
Thanks,

I looked into QSignalMapper, but it seems to have limitations, for example you can only pass one parameter and you can really just map one slot/signal.

I could probably make it work by passing a structure (and register that with the meta compiler), and then use multiple QSignalMappers... but, at least for my case, I find that creating my own object to be much simpler both to implement and to read.

@SGaist
Yes. That was intensional. I just tested that my installation is still providing the message.
Thanks a lot anyway.

I figured it out. I needed to set my QObject and QCore stuff properly. In the .pro file of the shared library, I added:

QT += core

In the shared library's .h file, I switched this:

class CTSCANSHARED_EXPORT ctScan { public: ...blah blah...

with this:

class CTSCANSHARED_EXPORT ctScan: public QObject { Q_OBJECT public: ...blah blah...

And then ensured the shared library's .h file had this:

#include <QObject>

And then it compiled properly.

Hi,

You can't pass a parameter when setting up the connection and since your using Qt 5 you should try the new connect syntax, it helps avoid that mistake.

There also the possibility of using lambdas for such use case.

I would have expected that all Qt type are already registered. However, this is a template which you registered with template argument. That is presumably the reason. A template delivers infinite possibilities. I did not know.

@swegmann

Yeah, it did the trick. Thanks

@Chris-Kawa

Thank you very much!

@SGaist said:

@sierdzio Indeed the back ticks are not mandatory, however it gives the forum engine a good hint of what is following

in the cheat sheet you can actually find:
Blocks of code are either fenced by lines with three back-ticks ```, or are indented with four spaces. I recommend only using the fenced code blocks -- they're easier and only they support syntax highlighting.

The question is what is the syntax highlighting now?

Hi,

Short answer: no

The slot signature must either have the same number or less parameters than the signal and the type must be the same.

@jelicicm
the exec() is typically called with a return at last position in main. Exec starts the event loop and continues until you quit the whole application.

I recommend that you check out the example delivered with QtFtp
This provides you a better start.

When using Qt it is recommended to have a sound basis of C++. Your code looks as you are more familiar with C. It may help your understanding to go through some C++ tutorial, if you are not familiar with OOP and C++.