Wrong C++ syntax

[anneranch]

Come on, quit screwing around here. Your original post asked how to connect a signal and slot between two QListWidget instances. The final code I posted would do that, using a lambda function instead of an actual slot. Now you say, I didn't want to connect to another list widget after all, I wanted to connect the list widget to a QPlainTextEdit.

You need to remember some basic C++. Signals and slots are no different from ordinary methods of C++ classes. They are labeled with "signals:" and "slots:" keywords in Qt so that the MOC compiler can recognize them and create the code in the moc_*.cpp file that implements them and makes the first style of connect() work at runtime. A lambda function is just a fancy way to write a nameless C++ function that gets compiled in place.

All the rules of C++ apply to signals, slots, and lambdas: If you want to call one of these functions, you have to supply the correct number and types of arguments to it. You can't call a function that expects one type of pointer using an argument that is a different type. It's basic C++, pure and simple.

Sorry, but my objective, in case I did not say it - is to replace QtDesigner signal / slot in XML with C++ code.
The XML works by coping a string from list and appending it to plain text.

I initially started with list to list and have been getting "invalid function " when using "addItem", even when intelisense lets me use "addItem".
So I assumed I am using wrong syntax and still like to verify my mistake, irregardless if passing between item or plain text.
At this point I am not interested in bypassing my error using lambda - if XML works so should new or old style C++ "connect" work.

[d_stranz]

I am not interested in bypassing my error using lambda

Using a lambda expression does not bypass anything. It is simply an alternative to defining an actual slot or other method with the correct function signature. In your original post with two list widgets, you couldn't use the new style version of connect() that uses the QOverload<> syntax because your version of Qt is probably too old, and you couldn't use the old style version because it requires addItem() to be a slot and it isn't.

Now in your new code you are trying to connect a signal that sends an apple to a slot that wants an orange. Your error seems to be in thinking that somehow you can connect something to anything else and arguments will magically get converted. As I said already, signals and slots are just C++ functions, and you can't call a C++ function with the wrong number or types of arguments.

The XML works by coping a string from list and appending it to plain text.

How is that possible? There is no itemClicked() signal from QListWidget that sends a text string, so it is not possible in QtDesigner or anywhere else to connect a QListWidget itemClicked() signal to -any- slot that expects a text string as an argument. The ui XML code will compile, because the UIC and MOC compilers will create the old style connect() statement in its code, but it will not work at run time because the function signatures do not match.

The only QListWidget signal that returns a string is currentTextChanged(). So the only possible working signal / slot connection you could have made in QtDesigner would be to connect QListWidget::currentTextChanged() to QPlainTextEdit::appendPlainText(), and that will result in whatever text was clicked on in the list widget getting copied and appended to the text edit. Neither the signal nor the slot are overloaded methods, so you could use either the old or new style of connect() to make the connection.

connect( ui->list, SIGNAL( currentTextChanged( const QString & ) ), ui->plainTextEdit, SLOT( appendPlainText( const QString & ) ) );
 
// or
 
connect( ui->list, &QListWidget::currentTextChanged, ui->plainTextEdit, &QPlainTextEdit::appendPlainText );

connect( ui->list, SIGNAL( currentTextChanged( const QString & ) ), ui->plainTextEdit, SLOT( appendPlainText( const QString & ) ) );

// or

connect( ui->list, &QListWidget::currentTextChanged, ui->plainTextEdit, &QPlainTextEdit::appendPlainText );

To copy to clipboard, switch view to plain text mode 

In any case, there is no execution of XML code. The XML file edited by QtDesigner is simply instructions to the UIC and MOC compilers that tell them how to generate the C++ code that defines the user interfaces and instantiate it at run time, including making any signal and slot connections that have been defined in the ui file. That C++ code will always compile because connect() statements that get generated are the old style, which use method names as strings and not as addresses of member functions (as the new style does). New style connect() statements will fail to compile if the functions do not match. Old style connect() will compile, but at run time will fail because Qt's meta-object system will not be able to match up the function at that time.

[anneranch]

Partial success.
Using both old and new "connect" style throws "segmentation fault" at either one.

It is my understanding that "connect" code placement is not critical - however my crash occurs exactly on "connect" which I have placed in a secondary dialog constructor. My main window dialog is primary.

RTFM implies that passing null pointer may be the problem...

[d_stranz]

It is my understanding that "connect" code placement is not critical

No, not true. You must connect the signal and slot before any of the signals you want to process can be issued. The customary place to make the connection is in the constructor of the parent of the two widgets you want to connect. This ensures that the connection is made only once and before either of the connected widgets can do anything. There are other places, but this is the most common.

RTFM implies that passing null pointer may be the problem...

Almost always either a null pointer or a pointer that has not been initialized. If you are passing a pointer in to your secondary dialog via a function call, then calling connect() using the variable that holds that pointer before you have made that call (i.e. in the dialog constructor) means you are using an uninitialized pointer.