Hi,

Fortunately for you Qt is very intuitive that way : you just have to implement the resizeEvent method.

If you can't, just edit the thread title and prepend [solved]

Hmm, it should work.

Can you post the code?

Sorry for the late reply, the page says that there's nothing to be found

Are you sure the signal isn't getting emitted or is it a getting emitted but the sendmail object isn't picking it up? My guess is your send mail object is doing something (locked up and never going back to the event loop). So it is never receiving that second message since it never gets back to the event loop.

Don't know for sure without seeing the code for it, but just something I've noticed in thread programming with Qt.

You could gdb to break into the application and see what your thread is doing. If it isn't in processEvents() that is probably the issue.

Oh and one more thing, you can easily test the emitter by create a fake sendmail object with that same slot, then just have it write to the console when it sees that signal. That way you know if is doing nothing but writing to the console and exiting the slot so there won't be any hang ups. My guess is it will work and that your problem lies in the sendmail object.

[edit]: added more ideas :)

@p3c0
Sure :)

Since you switched to QSqlTableModel, are you using it's functions to add new rows ?

Hi. You're right. There has to be a type. For objects, you should use "var".

signal closeClick(var options);

It is an object not because of the parameter type, but because of its content.

var options = {"cancel": false};

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.

@okieh

As it looks to me the installation of Qt 5.2.1 is broken. If possible you should also install the newest version of Qt libs IMHO.

However, from personal experience it might be also worthwhile to update your Ubuntu. I am operating a server with Ubuntu 12.04 and had quite a bit of trouble in connection Qt 5 there. Luckily the admin there, "some" version (5.0 or 5.1) to work at least moderately.
On Ubuntu 14.04 on my desktop everything worked like a charm.
Finally I like to state that I am developing on Windows. Therefore, my Linux knowledge is limited as well.

Qt developers have investigated this before, and there is a partially-working patch.

There are still a number of important challenges to work through, but devs are focussing on other things at the moment. It is not currently being actively worked on: http://comments.gmane.org/gmane.comp.lib.qt.devel/10327

Normally it calls others functions which manages the display, the first sequence receives datas from a bluetooth connection, the second sequence creates objects and displays them, the third one modifies them and the fourth one returns its value if it's changed by the user.

For example, if I want to display a line Edit :

I send a bluetooth trame with the instruction, the first sequence memorizes it,

Then, in the second sequence, I create it and add it on the mainwindow,

I add a texte and I modify some properties (like alignment, color, ...) in the third sequence,

Finally, if the user change its text value, the fourth sequence returns the new one by bluetooth when the signal editingFinished() return true

PS : Actually, I don't use bluetooth yet, I only fill an array which stand for buffer but after my tests are effective it will be replace by Bluetooth Low Energy

Hi there,

I'm not completely sure what you are asking. But if I'm understanding you correctly, you
want to implement the timeout() signal in your own way? I would suggest sub-classing the
QTimer object.

#include <QTimer> class CustomTimer : public QTimer { Q_OBJECT public: explicit CustomTimer(QObject *parent = 0); signals: void customSignal(/*parameters*/); public slots: void emitCustomSignal(); }; CustomTimer::CustomTimer(QObject *parent) : QTimer(parent) { connect(this, SIGNAL(timeout()), this, SLOT(emitCustomSignal())); } void CustomTimer::emitCustomSignal() { emit customSignal(/*parameters*/); }

@mcosta Actually, my problem is solved. Thanks to @t3685 for the solution. I've just forgot to mark it as SOLVED. Anyway, thanks ;)

Hi sneubert,
No I had forgotten to add that.

@kroman
Typically you can call the slots that signal is connected to as long as the slot routines are not private.

[edit:koahnig] should checked before.
in the description of signals and slots , you can find:
#Signals

Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Signals are public access functions and can be emitted from anywhere, but we recommend to only emit them from the class that defines the signal and its subclasses.*

@SGaist

Thanks. Now I have a more clear picture about signals.

What's weird is I tried the same code again today, but I'm getting the sender this time. Something is not right with how PySide passes the sender, but I can tell this is one of those bugs that will be really hard to track down since it's really inconsistent. Here's a simplified version of what I'm working with:

import sys from PySide.QtCore import * from PySide.QtGui import * class CustomDialog(QDialog): def __init__(self, parent=None): super(CustomDialog, self).__init__(parent) self.setLayout(QVBoxLayout()) self.table = QTableWidget() self.table.setColumnCount(2) self.layout().addWidget(self.table) self.table.setRowCount(10) for row in xrange(self.table.rowCount()): item = QTableWidgetItem(str(row)) self.table.setItem(row, 0, item) combo = QComboBox() combo.addItems(['one', 'two', 'three']) combo.currentIndexChanged.connect(self.onIndexChanged) self.table.setCellWidget(row, 1, combo) @Slot(int) def onIndexChanged(self, index): print self.sender() def main(): app = QApplication(sys.argv) dialog = CustomDialog() dialog.show() app.exec_() if __name__ == '__main__': main()

If you don't get the bug, I wouldn't spend too much time looking into it, but I appreciate the help.