Old program
-
Hi and welcome to devnet,
I guess you have the sources of your old program ?
If so first thing to do is to go through Qt's tutorials and examples to learn how it works.
Then, extract your old program business logic. Encapsulate it properly so it can be used independently of the GUI e.g. make only emit messages. Depending on what it did you might not need a thread at all.
Finally, create your GUI and integrate your business logic.
Hope it helps
-
ok so far so good, i have managed to implement classes.
Yes you are right i dont need extra thread.
but I have signal - slot issue
please could someone help me with this
my problem is that I can't update simple label from created class.
i am looking on this like:
when program started (mainwindow) it create instance of myclass
then I have to pass pointer of my mainwindow class to created myclass.
On myclass constructor connection with signal(function) are created and pointing to function in mainwindow class.mainwindow.h
@
#include <QMainWindow>
#include <typedefs.h>
#include <QTimer>
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
public slots:
void UpdateLabels(QString text);
private slots:
void on_pushButton_clicked();
....
void TimerEvent(); // working in class signal - slot
private:
Ui::MainWindow *ui;
QTimer timer;
};
@
mainwindow.cpp
@
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include<cf7.h>cf7 *cf;
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
...
cf =new cf7(this);// connect(cf, SIGNAL(updateUI(const QString)), ui, SLOT(UpdateLabels(const QString)));
cf->open(); cf->CF_Init(); cf->enable(); connect(&timer, SIGNAL(timeout()), this, SLOT(TimerEvent())); this->timer.start(100);}
void MainWindow::UpdateLabels(QString text) // updating function
{
ui->line6->setText(text);
}
@cf7.h
@
#include <typedefs.h>
#include <QObject>
...
#define device "/dev/ttyUSB0"class cf7 : public QObject{
Q_OBJECT
public:
cf7(QObject *parent);
int pooling(void);
int openZetonjeraPort(void);
int CF_Init(void);
signals:
void updateUI(QString text);
};
@
cf7.cpp@
#include "cf7.h"
#include "mainwindow.h"
#include <QDebug>
...
cf7::cf7(QObject *parent)
{
// connect(this,SIGNAL(updateUI(QString),)
//connect(this, SIGNAL(updateUI(QString)),parent, SLOT(UpdateLabels(QString)));
//connect(&cf, SIGNAL(updateUI(QString)), ui, SLOT(UpdateLabels(QString)));
}
int cf7:: pooling(void)
{
...serial stuff...
updateUI("HELLO");
return 0;
}
...
int cf7 :: open(void)
{
fz = open(device ,O_RDWR | O_NOCTTY | O_NONBLOCK);
if (fz <0)
{
exit(1);
}
tio.c_cflag = baud | CS8 | CREAD | CLOCAL| ICRNL ;
tio.c_oflag = 0;
tio.c_cc[VTIME] = 0;
tio.c_cc[VMIN] = 0;
tcflush(fz, TCIFLUSH);
tcsetattr(fz, TCSANOW, &tio);
return 0;
}
..
int cf7::CF_Init(void)
{
... serial stuffupdateUI("HELLO");
return 0;
}void cf7::updateUI (QString text)
{
.... UpdateLabels (text);
}
@of course im am getting UpdateLabels() was not declared in this scope
-
To update a label uncomment the following connect in c7 constructor.
@
connect(this, SIGNAL(updateUI(QString)),parent, SLOT(UpdateLabels(QString)));
@You don't need to define void cf7::updateUI(QString text) in cf7.cpp.
Just declare it as a signal, which you already did. -
You should just make a correction: connect your c7 updateUI signal in your MainWindow's constructor rather than in c7's constructor. It will make c7 completely independent of the GUI on top of it.
Also from a pure reading point of view, you should add the missing emit keyword, it will make your code easier to understand
-
What version of Qt are you using ?
-
I meant for your target
-
I am not using anything yet :)
question
For using with X11 I will install * Qt libraries 4.8.5 for Linux/X11 *
and for using directly to framebuffer i will install Qt libraries 4.8.5 for embedded Linux?
How applications behave with static build on linux targets? -
Pretty much it's that yes. Depending on what you will run on your target, you might need to compile Qt yourself.
I don't exactly understand your question about static application behavior
-
The application behavior won't change because of the build type. However you should first check that you can use a static build, there are licenses implication with it.
