сигналы Combobox

[Olzhas]

Всем добрый вечер.

Столкнулся со странной проблемой. Мне нужно сделать так, чтобы при изменения item'а combobox'а выполнялась некая функция XXX.

пробовал и так...
connect(ui.comboBox,SIGNAL(ui.comboBox->currentIndexChanged(QString& str)),this,SLOT(XXX()));

и через другие сигналы по- всякому, но упрямая функция так и не хочет выполняться.

Заранее спасибо.

[f0x]

убери str

[Olzhas]

не помогает(( я ж говорю как только не пробовал

[BRE]

Код

C++ (Qt)
connect( ui.comboBox, SIGNAL( currentIndexChanged( const QString & ) ), this, SLOT( XXX() ) );

[Olzhas]

Не помогло.
У кого- нибудь есть опыт удачной обработки сигналов от комбика, киньте пример плиз.

[BRE]

Не помогло.

Не верю. 

Покажи побольше кода и желательно, то что программа пишет в консоль при своей работе...

[SABROG]

Код

C++ (Qt)
connect( ui.comboBox, SIGNAL( currentIndexChanged( const QString & ) ), this, SLOT( XXX() ) );

Форматирование это конечно хорошо, но оно замедляет код при частом вызове connect. Qt удаляет все "const", "&" и пробельные символы. Это называется нормализацией, чтобы чуток повысить скорость Qt нужно помогать:

Код

C++ (Qt)
connect( ui.comboBox, SIGNAL(currentIndexChanged(QString)), this, SLOT(XXX()));
 

Qt никогда не передает параметры через сигналы или события в виде ссылок или указателей, объект всегда копируется.

[BRE]

Qt никогда не передает параметры через сигналы или события в виде ссылок или указателей, объект всегда копируется.

Что под этим подразумевается?
При DirectConnection вызов слота сводиться к прямому вызову метода. И если этот метод использует ссылки/указатели для передачи аргументов, то ему будут переданы ссылки/указатели.

[SABROG]

Что под этим подразумевается?

Когда я это писал, то подразумевал именно эвенты. Про Qt::DirectConnect забыл как-то. Ты прав, в этом случае всё как и ожидается. Если взять такой пример:

Код

C++ (Qt)
void MainWindow::on_pushButton_clicked()
{
    qDebug() << &str;
    emit someSignal(str);
}
 

Код

C++ (Qt)
void MainWindow::someSlot(const QString &str)
{
    qDebug() << &str;
}
 

То в зависимости от типа подключения:

Код

C++ (Qt)
QObject::connect(this, SIGNAL(someSignal(QString)), SLOT(someSlot(QString))/*, Qt::QueuedConnection*/);
 

Адреса объектов будут разными. При этом, если сигнатура будет такой:

Код

C++ (Qt)
private slots:
    void someSlot(QString);
signals:
    void someSignal(QString str);
 

То в обоих случаях в слоте someSlot() qDebug() выведет разные адреса. При Qt::DirectConnect другой адрес потому, что параметр передается не по ссылка, а по значению, а во втором случае потому, что Qt копирует объект, чтобы поместить его в очередь событий.

И для обоих вариантов сигнатура подключения одна и та же:

Код

C++ (Qt)
QObject::connect(this, SIGNAL(someSignal(QString)), SLOT(someSlot(QString)));
 

Но Qt это сама "разруливает". А такое уже не прокатит:

Код

C++ (Qt)
signals:
    void someSignal(const QString& str);
    void someSignal(QString str);
 

Причем еще на этапе компиляции. В C++ невозможно перегрузить метод принимающий параметр одного и того же типа, но с разным способом его передачи (по ссылке или по значению).

[BRE]

При этом, если сигнатура будет такой:

Код

C++ (Qt)
private slots:
    void someSlot(QString);
signals:
    void someSignal(QString str);
 

То в обоих случаях в слоте someSlot() qDebug() выведет разные адреса.

Вот-вот.
Даже при прямом подключении будет происходить копирование объекта. Для чего?

А еще в некоторых случаях, я могу захотеть сделать следующее:

Код

C++ (Qt)
signals:
	void	getData( QString &data );
 
...
 
void Obj::formData()
{
	QString str;
	emit getData( str );
 
	if( !str.isEmpty() )
		useData( str );
}
 

Но Qt это сама "разруливает". А такое уже не прокатит:

Код

C++ (Qt)
signals:
    void someSignal(const QString& str);
    void someSignal(QString str);
 

Причем еще на этапе компиляции. Это что же получается, в C++ невозможно перегрузить метод принимающий параметр одного и того же типа, но с разным способом его передачи?

Не возможно.

[SABROG]

Вот-вот.
Даже при прямом подключении будет происходить копирование объекта. Для чего?

Если в сигнатуре сигнала явно указана передача по ссылке, то копирование объекта будет только в случае Qt::QueuedConnection (ну или между потоками, что тоже самое). А если параметр передается по значению, то там и так понятно, это просто фишка C++. Просто для connect нет никакой разницы как ты передаешь по значению или по ссылке, скорее всего это закадровая работа moc'a.

Код

C++ (Qt)
А еще в некоторых случаях, я могу захотеть сделать следующее:
 

Тогда это:

Код

C++ (Qt)
QObject::connect(this, SIGNAL(someSignal(QString)), SLOT(someSlot(QString))/*, Qt::QueuedConnection*/);
 

Придется менять на это:

Код

C++ (Qt)
QObject::connect(this, SIGNAL(someSignal(QString&)), SLOT(someSlot(QString&))/*, Qt::QueuedConnection*/);
 

Иначе:

Код:

Object::connect: No such signal MainWindow::someSignal(QString)

То есть безболезненно можно менять только константные ссылки. Но при попытке такое провернуть через Qt::QueuedConnection получим:

Код:

QObject::connect: Cannot queue arguments of type 'QString&'
(Make sure 'QString&' is registered using qRegisterMetaType().)

[BRE]

Просто для connect нет никакой разницы как ты передаешь по значению или по ссылке, скорее всего это закадровая работа moc'a.

Для connect нет разницы, он работает с сигнатурами. Но если кто-то вслед за упрощением сигнатур, начнет упрощать объявления самих методов, то он может получить дополнительные тормоза из-за того же копирования аргументов.

[SABROG]

Для connect нет разницы, он работает с сигнатурами.

Разницы нет только в случае с константными ссылками.

Можно конечно утилиту заюзать, если не уверен в том, что делаешь (она кстати не распространяется в публичных архивах с исходниками Qt). Потом пару раз глянуть на то, что получается и уже самому вручную это делать.

[BRE]

Можно конечно утилиту заюзать, если не уверен в том, что делаешь (она кстати не распространяется в публичных архивах с исходниками Qt). Потом пару раз глянуть на то, что получается и уже самому вручную это делать.

Какое то ускорение работы connect конечно будет. Только, в большинстве случаев, само соединение происходит значительно реже чем вызов самого слота в процессе работы. А я уже привык, что написание аргументов в сигнале, должно совпадать с написанием аргументов в слоте и connect. И визуально это легко проверяется.
Поэтому, мне сейчас будет лениво, отдельно контролировать, что в слоте у меня const Data &, а в connect желательно писать просто Data, что бы упростить работу connect'у.
 

[SABROG]

Как правило смысл есть только если создается библиотека или плагин на основе Qt. Разработчик же никогда не знает каким образом будут использовать его библиотеку. Его задача обеспечить максимальное быстродействие при любой ситуации. Вообще я не помню, чтобы мне встречались примеры, где не константная ссылка используется в сигналах. Классы-обертки над указателями - да. Поэтому наверняка случай SIGNAL(MyClass) будет самым распространенным.