tags:

views:

188

answers:

2

Hi all,

NOTE: THE CODE PROVIDED JUST GIVES THE IDEA OF THE STRUCTURE OF THE APPLICATION

I have a Qt application, interfacing with external hardware. The structure is such that the class for interfacing with the hardware inherits from QObject and is composed with the main GUI thread class. Let's say the class is test.h, here is its sample code:

#ifndef TEST_H
#define TEST_H

#include <QLineEdit>
#include <QString>
#include <QTimer>
#include "ui_test.h"

#define TIMEOUT 100
class TestObj;
class TestApp:public QWidget, public Ui::mTestForm
{
    Q_OBJECT

public:
    TestApp(QWidget* parent=0);
    QTimer* mTimer;
    bool mWindowClosed;
    TestObj* mObj;

public slots:
    void UpdateText();
    void Exit();
};

class TestObj:public QObject
{
    Q_OBJECT
public:
    TestObj();
    void RandomTest();
};
#endif

Code for test.cpp is

#include "test.h"

TestApp::TestApp(QWidget* parent):QWidget(parent)
{
    setupUi(this);
    mObj = new TestObj();
    mWindowClosed=false;
    mLineEdit->setText("Hello");
    mTimer=new QTimer();
    mTimer->singleShot(1000,this,SLOT(UpdateText()));
    connect(mExitButton,SIGNAL(clicked()),this, SLOT(Exit()));
}

void TestApp::UpdateText()
{
    if(mWindowClosed)
    {
    //QApplication::processEvents();
     return;
    }
    else
    {
    //QApplication::processEvents();
     mObj->RandomTest();
     mLineEdit->setText("Hi");
     mTimer->singleShot(100,this,SLOT(UpdateText()));
    }
}

void TestApp::Exit()
{
    mWindowClosed=true;
}

Now consider that TestObj class is the one used to interface with the hardware. This class sends three possible commands (in actual code, the above is just a sample structure) with different timeouts to the hardware, thus we have a timer which is used when sending commands (implemented as functions) to the hardware. Each of these has a processEvents entry to identify any changes to variables in the meanwhile.

The problem is this module is responsible for a steady rise in memory during program execution.

When I comment out the UpdateText() function in the TestApp constructor, the app works fine.

My guess is that most likely there is queuing of signal slots due to which the memory increase, because there are lots of GUI events taking place. And since the class isn't implemented as a separate thread and clubbed with the main GUI thread. There is continuous update of the main thread.

Can someone suggest a way out? I don't have the authority to change the design otherwise I would have implemented the interface class as a thread. So if a solution can be suggested with the current design as is, it would be beneficial.

A: 

Wild guess:

Try changing this:

mTimer->singleShot(100,this,SLOT(UpdateText()));

to this:

if (!slotSet) 
{
    mTimer->singleShot(100,this,SLOT(UpdateText()));
    slotSet = true;
}
Vijay Mathew
this cannot be done as I have to continuously send commands to the h/w
rocknroll
A: 

Creating a regular timer, setting its interval to 100 and connecting its timout signal to the UpdateText function will avoid events piling up.

P.S: You don't need a QTimer object for singleShot, you can call QTimer::singleShot directly.

rpg
thanks for considering my question but it is not about the QTimer object.
rocknroll