1

A google search gives these as the top three results:

According to those, it seems like it ought to "just work" like anything else. But this code doesn't:

EditorList::EditorList(..., QWidget* parent) :
    QWidget(parent)
{
    ...
    Processing* processing = Processing::getInstance();
    connect(this, SIGNAL(reorderDelete(DataSequence*,ListType,QList<int>)), processing, SLOT(reorderDelete(DataSequence*,ListType,QList<int>)));
    ...
    buttonDelete = new QPushButton(this);
    connect(buttonDelete, SIGNAL(clicked(bool)), this, SLOT(buttonDeleteClick()));
    ...
}
...
void EditorList::buttonDeleteClick()
{
    ...
    QList<int> locations;
    ...
    emit reorderDelete(mySequence, myListType, locations);    //breakpoint 1 here
}

//-----------------------------------------------------------------

void Processing::reorderDelete(DataSequence* sequence, ListType listType, QList<int> locations)
{
    if(sequence)    //breakpoint 2 here
    {
        sequence->reorderDelete(listType, locations);
    }
}

The reason for this structure, instead of calling mySequence->reorderDelete directly, is to have it done in Processing's thread instead of the UI's. I hope I haven't stripped out too much detail to show the problem; this is a rather large project.

When I click my delete button, I hit breakpoint 1 (so far, so good), but I don't hit breakpoint 2. My other signals/slots work across threads, but their connects are not in constructors. I want to make this one automatic so that every instance is "just connected" without having to remember to do it. Can I not do that?

eyllanesc
  • 235,170
  • 19
  • 170
  • 241
AaronD
  • 503
  • 1
  • 7
  • 23

2 Answers2

2

Okay, I got it. Leaving up for others to find.

According to this, my ListType enum was blocking the system from making the connection. It only works with system-known datatypes because emitting a SIGNAL actually stores a copy for the SLOT(s) to read later. I knew that, but I thought it was more like a stack frame that could take anything. Apparently not.

It also works to put a call to qRegisterMetaType<ListType>("ListType"); somewhere before the connect. (I put it in my main window's constructor.) This makes the datatype known so that the connection can work anyway.

I'm hitting both breakpoints now.

AaronD
  • 503
  • 1
  • 7
  • 23
  • That's great that this worked, i just wanted to suggest changes in the code, which will aim creating some pipe for asynchronous purposes. I had same issue while passing complicated data structures through signal emitting, so avoiding it is one of the solution.. + for `qRegisterMetaType("ListType");` solution. – Guillotine Sep 16 '17 at 00:16
  • @Guillotine `...aim creating some pipe for asynchronous purposes` is a bit hard for me to figure out. You mean like leaving an explicit copy of the object somewhere else instead of sending it through the connection? I can see that being an advantage in some situations, or I could pass a pointer if I don't need a snapshot of that exact time. – AaronD Sep 16 '17 at 00:28
0

Make sure you have used Q_OBJECT macros in your class

asashnov
  • 109
  • 6