killing Qt timer.

[jaxrpc]

Hi, i have a Qt timer that emits timeout() every 500ms (interval set to 500ms, setSingleShot = true)

so in my slot for the timeout()

i do some processing and call timer->start(); so that it will continue to call timeout.

the problem comes when i close the program using the X close button at the top right of the window. I realised that my Qt program is still running in the background.. most prob the timer did not get killed cleanly.

how do i solve problems like this?

thanks man.!

[SixDegrees]

Unless you call your application's close() slot, closing the window will simply close the window - it won't shut down the application. At some point, you have to explicitly call close() if you want the application to terminate.

[jaxrpc]

Unless you call your application's close() slot, closing the window will simply close the window - it won't shut down the application. At some point, you have to explicitly call close() if you want the application to terminate.

hi, sorry i am pretty new to Qt so where do you think is the best place to place the close()?

Will pressing on the x button emit some sort of signal?

thanks

[ChrisW67]

How you create the timer may have some bearing on this problem. Muisei has already suggested one way to make sure the timer object is deleted. Typical setup for the main window in Qt will exit when the user clicks the "X' control, presses Alt-F4 (or equiv), or the code explicitly calls close() on the last remaining top-level window etc. If the timer's parent is the window then it goes too.

Can you post a small example that behaves this way?

[jaxrpc]

How you create the timer may have some bearing on this problem. Muisei has already suggested one way to make sure the timer object is deleted. Typical setup for the main window in Qt will exit when the user clicks the "X' control, presses Alt-F4 (or equiv), or the code explicitly calls close() on the last remaining top-level window etc. If the timer's parent is the window then it goes too.

Can you post a small example that behaves this way?

the codes are very long so i will just post how it works.

I have a class that contains a member timer

When my mainWindow loads, it will create a new instance of that class with the timer and starts it.

that's about it.

[ChrisW67]

OK so the timer does not go out of scope until the containing object (let's call it T) does. If the main window (M) creates the T object on the stack, i.e. T as a member variable of M, then T is destroyed when M is. If M allocated T on the heap, i.e. by new statement, then M must delete T directly (in M::~M) or make sure something else does: make T an Q_OBJECT (if it isn't already) and allocate T with M as parent.

The point of asking for a small example displaying the behaviour is to distil the problem to its bare essentials and remove any surrounding confusing influences. Often the process of doing this is enough to make the actual problem obvious. The code below shows both heap and stack approaches.



#include <QtCore>
#include <QtGui>

class M1: public QMainWindow
{
Q_OBJECT

public:
M1() {
count = 0;
setWindowTitle("Timer on stack");
l = new QLabel("", this);
setCentralWidget(l);
connect(&t, SIGNAL(timeout()), this, SLOT(onTimeout()));
t.start(500);
};

public slots:
void onTimeout() { l->setText(QString::number(++count, 10)); };

private:
QTimer t;
QLabel *l;
int count;
};


class M2: public QMainWindow
{
Q_OBJECT

public:
M2() {
count = 0;
setWindowTitle("Timer on heap");
l = new QLabel("", this);
setCentralWidget(l)
t = new QTimer(this); // Qt will look after delete-ing the timer
connect(t, SIGNAL(timeout()), this, SLOT(onTimeout()));
t->start(500);
};

public slots:
void onTimeout() { l->setText(QString::number(++count, 10)); };

private:
QTimer *t;
QLabel *l;
int count;
};

int main(int argc, char **argv)
{
QApplication a(argc, argv);

M1 m1;
M2 m2;
m1.show();
m2.show();

return a.exec();
}