I am just learning Qt and have a very basic question.
If there is a (function scope) variable in a slot, and the slot is called multiple times, each time before the last call has returned (is this even possible?), will the variable be overwritten each time? In the sense that, if the slot is called before the previous run has returned, wouldn't that cause errors?
Thanks.
Yes if the calls are made from different threads AND you are using direct connection.
If you use queued connections then the slot calls will be performed one after another on event loop which is ran on the thread your receiving object belongs to. (edit thanks to Idan K comment).
Checkout Signal and slots's queued connection or QMutexLocker to solve your problem.
If you truly use function scope variables, then it shouldn't matter. Example:
class WheelSpinner : public QThread
{
Q_OBJECT;
public:
WheelSpinner( QObject* receiver, const char* slot )
{
connect( this, SIGNAL( valueChanged( int ) ), receiver, slot,
Qt::DirectConnect );
}
void run()
{
for ( int i = 0; i < 100000; ++i )
{
emit ( valueChanged( i ) );
}
}
public signals:
void valueChanged( int value );
};
class ProgressTracker : public QObject
{
Q_OBJECT;
public:
ProgressTracker() { }
public slots:
void updateProgress( int value )
{
// While in this function, "value" will always be the proper
// value corresponding to the signal that was emitted.
if ( value == 100000 )
{
// This will cause us to quit when the *first thread* that
// emits valueChanged with the value of 100000 gets to this point.
// Of course, other threads may get to this point also before the
// program manages to quit.
QApplication::quit();
}
}
};
int main( int argc, char **argv )
{
QApplication app( argc, argv );
ProgressTracker tracker;
WheelSpinner spinner1( &tracker, SLOT( updateProgress( int ) ) );
WheelSpinner spinner2( &tracker, SLOT( updateProgress( int ) ) );
WheelSpinner spinner3( &tracker, SLOT( updateProgress( int ) ) );
spinner1.run();
spinner2.run();
spinner3.run();
return ( app.exec() );
}
As long as the function is reentrant there is no problem.
Related
I am having a difficulty in understanding qwt oscilloscope example.
i understand most of the program roughly, but i can not find the linkage between samplingthread class and plot class.
It seems like chart samples are from samplingthread and it is provided to QwtPlotCurve object in plot class.
However i can not find linkage between samplingthread object and plot object. But when i change the frequency value in samplingthread object, it is applied and appears on plot object (canvas).
Below is part of code (from main.cpp) i do not really understood but please reference full project (need decompress i think) by downloading from
http://sourceforge.net/projects/qwt/files/qwt/6.1.2/.
int main( int argc, char **argv )
{
QApplication app( argc, argv );
app.setPalette( Qt::darkGray );
MainWindow window;
window.resize( 800, 400 );
SamplingThread samplingThread;
samplingThread.setFrequency( window.frequency() ); // window.frequency()'s type is double
samplingThread.setAmplitude( window.amplitude() ); // window.amplitude()'s type is double
samplingThread.setInterval( window.signalInterval() ); // window.signalInterval()'s type is double
window.connect( &window, SIGNAL( frequencyChanged( double ) ),
&samplingThread, SLOT( setFrequency( double ) ) );
window.connect( &window, SIGNAL( amplitudeChanged( double ) ),
&samplingThread, SLOT( setAmplitude( double ) ) );
window.connect( &window, SIGNAL( signalIntervalChanged( double ) ),
&samplingThread, SLOT( setInterval( double ) ) );
window.show();
samplingThread.start();
window.start();
bool ok = app.exec();
samplingThread.stop();
samplingThread.wait( 1000 );
return ok;
}
above's window.start() is equal to plot->start().
and i can not find the linkage between plot object and samplingthread object.
Can anyone explain this part for me?
signal/slot between 2 threads ends up as QEvents in the Qt event queue. Considering, that the sampling thread creates values very fast ( f.e every 10ms ) it is obvious, that this is no option.
So there needs to be a shared buffer, where writing/reading is guarded by a mutex - this is what SignalData is.
The bridge between SignalData and the curve is done by CurveData, that implements a given API. If you like you could compare CurveData with the idea of QAbstractItemModel.
But the oscilloscope application is more a demo than an example. It shows what is possible with very low CPU usage ( runs nicely even on the Pi with reasonable CPU usage ) with using a couple of tricks.
There is a use of a curious singleton pattern based on the class SignalData.
First of all, the singleton :
class CurveData: public QwtSeriesData<QPointF>
{
public:
const SignalData &values() const;
SignalData &values();
...
};
const SignalData &CurveData::values() const
{
return SignalData::instance();
}
QPointF CurveData::sample( size_t i ) const
{
return SignalData::instance().value( i );
}
On one side
Plot::Plot( QWidget *parent ):
{
d_curve = new QwtPlotCurve();
...
d_curve->setData( new CurveData() ); //singleton being used inside each curvedata
...
}
And on the other
void SamplingThread::sample( double elapsed )
{
if ( d_frequency > 0.0 )
{
const QPointF s( elapsed, value( elapsed ) );
SignalData::instance().append( s ); //singleton being used
}
}
I'll refrain from using this example as it is.
I'm developing a Symbian application.
I've written a system for easily changing views, roughly like this:
class ViewManager : public QWidget {
public slots:
void changeView( const QString &id ) {
if( currentView_m ) {
delete currentView_m;
currentView_m = 0;
}
if( id == "main" ) {
currentView = new MainView( this );
}
else if( ... ) {
//etc..
layout_m->addWidget( currentView_m );
connect( currentView_m, SIGNAL( changeView( QString ) ),
this, SLOT( changeView( QString ) ) );
}
private:
View *currentView_m;
};
class View : public QWidget {
signals:
void ChangeView( const QString &id );
};
class MainView : public View {
public slots:
void onButtonClicked() {
emit changeView( "someview" );
}
};
Then as an example, I'm using the ViewManager in main:
int main( int argc, char *argv[] ) {
QApp app...
ViewManager man;
man.changeView( "main" );
app.exec();
}
When I change the view the first time, it works just fine, then when I change the view another time, it segfaults! You might think it segfaults when I delete the currentView_m pointer, but no! The segmentation fault happens right after the program exits the changeView-slot.
I have no idea how to debug this, as the program crashes and shows a disassembler dump, and the stack trace shows only gibberish.
Could it be that after the slot call, the program goes to the QApplication event loop and crashes there? I'm using a custom widgets inside View implementations that override some of the protected QWidget events.
You are deleting a object the signal of which you are processing. Instead of delete, just call deleteLater() on the object, deferring the deletion to a "safe" point.
Try removing the view from your layout first. Then delete the view. You can use removeWidget,removeItem methods of layout for this purpose
Layout might be trying to access a delete view.
Read this Qt - remove all widgets from layout? question as well. It might give you insight.
How to use QPainter and QTimer to draw a real time sinusoid like
sinus( 2 * w * t + phi )
thanks.
I would assume something like this, for the interaction between QTimer and painting:
// Periodically paints a sinusoid on itself.
class SinPainter : public QWidget
{
Q_OBJECT
public:
SinPainter( QWidget *parent_p = NULL ) :
QWidget( parent_p ),
m_timer_p( new QTimer( this ) ),
m_t( 0.0 )
{
// When the timer goes off, run our function to change the t value.
connect( m_timer_p, SIGNAL( timeout() ), SLOT( ChangeT() ) );
// Start the timer to go off every TIMER_INTERVAL milliseconds
m_timer_p->start( TIMER_INTERVAL );
}
// ...
protected slots:
void ChangeT()
{
// Change m_t to the new value.
m_t += T_INCREMENT;
// Calling update schedules a repaint event, assuming one hasn't
// already been scheduled.
update();
}
protected:
void paintEvent( QPaintEvent *e_p )
{
QPainter painter( this );
// Use painter and m_t to draw your current sinusoid according
// to your function.
}
private:
QTimer *m_timer_p;
double m_t; // <-- Or whatever variable type it needs to be.
};
I am new to QT and I am doing some learning.
I would like to trigger a slot that modify a GUI widget from a C++ thread(Currently a Qthread).
Unfortunatly I get a: ASSERTION failed at: Q_ASSERT(qApp && qApp->thread() == QThread::currentThread());
here is some code:
(MAIN + Thread class)
class mythread : public QThread
{
public:
mythread(mywindow* win){this->w = win;};
mywindow* w;
void run()
{
w->ui.textEdit->append("Hello"); //<--ASSERT FAIL
//I have also try to call a slots within mywindow which also fail.
};
};
int main(int argc, char *argv[])
{
QApplication* a = new QApplication(argc, argv);
mywindow* w = new mywindow();
w->show();
mythread* thr = new mythread(w);
thr->start();
return a->exec();
}
Window:
class mywindow : public QMainWindow
{
Q_OBJECT
public:
mywindow (QWidget *parent = 0, Qt::WFlags flags = 0);
~mywindow ();
Ui::mywindow ui;
private:
public slots:
void newLog(QString &log);
};
So I am curious on how to update the gui part by code in a different thread.
Thanks for helping
stribika got it almost right:
QMetaObject::invokeMethod( textEdit, "append", Qt::QueuedConnection,
Q_ARG( QString, myString ) );
cjhuitt's right, though: You usually want to declare a signal on the thread and connect it to the append() slot, to get object lifetime management for free (well, for the price of a minor interface change). On a sidenote, the additional argument:
Qt::QueuedConnection ); // <-- This option is important!
from cjhuitt's answer isn't necessary anymore (it was, in Qt <= 4.1), since connect() defaults to Qt::AutoConnection which now (Qt >= 4.2) does the right thing and switches between queued and direct connection mode based on QThread::currentThread() and the thread affinity of the receiver QObject at emit time (instead of sender and receiver affinity at connect time).
In addition to stribika's answer, I often find it easier to use a signal/slot connection. You can specify that it should be a queued connection when you connect it, to avoid problems with the thread's signals being in the context of its owning object.
class mythread : public QThread
{
signals:
void appendText( QString );
public:
mythread(mywindow* win){this->w = win;};
mywindow* w;
void run()
{
emit ( appendText( "Hello" ) );
};
};
int main(int argc, char *argv[])
{
QApplication* a = new QApplication(argc, argv);
mywindow* w = new mywindow();
w->show();
mythread* thr = new mythread(w);
(void)connect( thr, SIGNAL( appendText( QString ) ),
w->ui.textEdit, SLOT( append( QString ) ),
Qt::QueuedConnection ); // <-- This option is important!
thr->start();
return a->exec();
}
You need to use QMetaObject::invokeMethod. For example:
void MyThread::run() {
QMetaObject::invokeMethod(label, SLOT(setText(const QString &)), Q_ARG(QString, "Hello"));
}
(The above code comes from here: http://www.qtforum.org/article/26801/qt4-threads-and-widgets.html)
I don't think you are allowed to call directly things that results in paint events from any
other threads than the main thread. That will result in a crash.
I think you can use the event loop to call things asynchronously so that the main gui thread picks up and then does the updating from the main thread, which is what cjhuitt suggests.
I am trying to write an OpenGL visualization program for some scientific data using Qt. I would like to be able to use my existing program unchanged and simply be able to call the glwidget and tell it to update the data at the end of each time step. However in order to run a Qt program it appears you have to use QApplication and then qt.run() which blocks the cpu.
Here is the pseudo code
main()
{
..set up stuff
myVisualizer = new myGLWidget();
for(int i=0;i<1000;i++)
{
..do calculations
myVisualizer.update(new data)
}
}
I realize that I could put all of my existing code in to a QThread and have it send a signal whenever it is done to connect to an update. It would just be easier this way. Does anybody have an idea how to solve this?
If you really don't want to investigate the threaded solution, which would be nicer all around, you can use the special-case timeout with 0. Basically, when you run a timer with a timeout of 0, it runs the appropriate code after processing the events that are currently on the event queue. So, you could set up something like this:
class MyDialog : public QDialog
{
Q_OBJECT
public:
MyDialog()
{
m_step = 0;
QTimer::singleShot( 0, this, SLOT( Process() ) );
}
public slots:
void Process()
{
// do calculations
m_step++;
QTimer::singleShot( 0, this, SLOT( Redraw() ) );
if ( m_step != 1000 )
QTimer::singleShot( 0, this, SLOT( Process() ) );
}
void Redraw() { // do redrawing code here }
private:
int m_steps;
};
And then combine it with the Qt-proper main code:
int main( int argc, char** argv )
{
QApplication app( argc, argv );
MyDialog dialog;
dialog.show();
return ( app.exec() );
}
You can use QThread in your application and do the calculations in a seperate thread.
What you have to do is to subclass the QThread and implement the run() method.
You can create a calculator class and add some signals in that class and connect the signal to your display widget's update slot (in this case QGLWidget::updateGL()).
Here is a rough example: (All you have to is to create a thread and DisplayWidget in your main() function and set the thread's DisplayWidget.)
class Calculator: public QObject
{
Q_OBJECT
public:
Calculator();
void start();
signals:
void updateDisplayWidget(/* you can put the resulting data */);
};
class DisplayWidget(): public QGLWidget
{
Q_OBJECT
// override paint methods here
public slots:
void slotUpdateDisplayWidget(/* you can receive the resulting data*/);
};
class MyThread : public QThread
{
public:
void run();
void setDisplayWidget(DisplayWidget* displayWidget);
private:
Calculator mCalculator;
};
void MyThread::run()
{
mCalculator.start();
exec();
}
MyThread::setDisplayWidget(DisplayWidget* displayWidget)
{
displayWidget->moveToThread(this);
connect(&mCalculator, SIGNAL(updateDisplayWidget()), displayWidget, SLOT(slotUpdateDisplayWidget()));
}