Comme vous le voyez, c’est tr\u00e8s simple. Nous h\u00e9ritons de QThread, nous avons deux membres dans cette classe: un pointeur vers une instance de la classe COMMAND (utile pour l’impl\u00e9mentation du patterns du m\u00eame nom) et un bool\u00e9en qui nous permet de d\u00e9terminer le sens de l’action “annuler” (undo) ou “normal” (undo == false). bien entendu, il est possible d’avoir autant de param\u00e8tre que vous le souhaitez. Il ne faut pas oubli\u00e9 de red\u00e9finir la fonction run().<\/p>\n
\/\/ l’impl\u00e9mentation<\/p>\n
#include \"thread.h\"\r\n\r\nThread::Thread(COMMAND* _mycommand,bool _undo)\r\n : mycommand(_mycommand),undo(_undo)\r\n{\r\n\r\n}\r\nvoid Thread::run()\r\n{\r\n if<\/b>(undo)\r\n mycommand->undo();\r\n else<\/b>\r\n mycommand->doCommand();\r\n}\r\n<\/pre>\nDans le constructeur, je d\u00e9finis les donn\u00e9es membres. La fonction run ex\u00e9cute la commande en fonction du param\u00e8tre undo. Il faut savoir que tout le code appel\u00e9 dans run sera ex\u00e9cut\u00e9 dans un thread diff\u00e9rent.
\n\u00c0 ce stade, nous avons une classe Thread qui est pr\u00eate \u00e0 recevoir et ex\u00e9cuter une “command”.<\/p>\n
Nous allons voir maintenant comment cr\u00e9er un design pattern command.<\/p>\n
Impl\u00e9menter le design pattern command<\/h2>\n
Ce pattern est tr\u00e8s utile pour g\u00e8rer l’annulation d’une action ou par exemple refaire la derni\u00e8re action. Il consiste \u00e0 cr\u00e9er une classe pour chaque action (du moins toutes les actions que vous voulez pouvoir modifier ou dans notre cas, ex\u00e9cuter dans un thread). Qt fournit des outils pour faire \u00e7a. Dans un cadre formateur, je pr\u00e9f\u00e8re l’impl\u00e9menter enti\u00e8rement.
\nIl faut tout d’abord \u00e9crire la classe abstraite qui d\u00e9finit une commande. Cela permettra \u00e0 notre classe thread de bien int\u00e9ragir avec la commande.<\/p>\n
#ifndef COMMAND_H\r\n#define COMMAND_H\r\n#include <QObject>\r\nclass<\/b> COMMAND : public<\/b> QObject\r\n{\r\n Q_ObJECT<\/b>\r\n\r\npublic<\/b>:\r\n virtual<\/b> void doCommand()=0;\r\n virtual<\/b> void undo()=0;\r\nsignals<\/b>:\r\n void Maximum(int M);\r\n void Minimum(int m);\r\n void valueChanged(int v);\r\n void done();\r\n};\r\n\r\n#endif \/\/ COMMAND_H<\/i>\r\n<\/pre>\nIl y a deux m\u00e9thodes abstraites pures: l’une pour faire la commande, l’autre pour l’annuler. J’ai ajout\u00e9 quelques signaux pour que la commande communique avec le thread principal pour informer l’utilisateur de l’avanc\u00e9e du la t\u00e2che en cours. Toutes les futures commandes de notre application doivent \u00eatre des sous-classes de COMMAND. Vous l’avez devin\u00e9, il faut impl\u00e9menter une commande, maintenant.
\nNotre commande sera vraiment basique, c’est une commande d’attente (so useless).<\/p>\n
\/\/wait.h<\/p>\n
#ifndef WAIT_H\r\n#define WAIT_H\r\n#include \"command.h\"\r\nclass<\/b> WAIT : public<\/b> COMMAND\r\n{\r\npublic<\/b>:\r\n WAIT();\r\n\r\n virtual<\/b> void doCommand();\r\n virtual<\/b> void undo();\r\n\r\n};\r\n\r\n#endif \/\/ WAIT_H<\/i>\r\n<\/pre>\nRien de particulier, juste la re-d\u00e9finition des fontions virtuelles pures. Voici leurs impl\u00e9mentations<\/p>\n
#include \"wait.h\"\r\nWAIT::WAIT()\r\n{\r\n\r\n}\r\n\r\nvoid WAIT::doCommand()\r\n{\r\n\r\nint step = 10;\r\n emit<\/b> Maximum(100);\r\n int i = 0;\r\n int k = 0;\r\n emit<\/b> Minimum(i);\r\n for<\/b>(int j = 0 ; j< 1000 ; j++)\r\n {\r\n sleep(0.5); \/\/fake statement<\/i>\r\n if<\/b>(i>=step)\r\n {\r\n emit<\/b> valueChanged(++k);\r\n i = 0;\r\n }\r\n i++;\r\n\r\n }\r\n emit<\/b> valueChanged(++k);\r\n emit<\/b> done();\r\n}\r\n\r\nvoid WAIT::undo()\r\n{\r\n\r\n}\r\n<\/pre>\nDans notre “doCommand”, nous calculons le pas de la notification de l’application principale. Ici, j’ai arbitrairement choisi 10 mais dans un contexte utile, le pas est \u00e9gal \u00e0 la taille de vos donn\u00e9es \u00e0 traiter divis\u00e9 par le nombre de notification que vous voulez.
\nNous \u00e9mettons la valeur maximale. Initialisation des variables temporaires (i et k). On \u00e9met i (0). Nous faisons une bouble sur chaque \u00e9l\u00e9ment \u00e0 traiter, on fait le traitement et on calcule un peu pour savoir s’il faut ou pas pr\u00e9venir l’application principale.
\nIl est bon de ne pas pr\u00e9venir \u00e0 chaque fois, car si vous travaillez sur plusieurs milliers ou millions de donn\u00e9es le traitement des signaux ralentira un peu votre application. Comme exemple, imaginez que vous travaillez sur chaque pixel d’une grosse photo.<\/p>\n
Il ne reste plus qu’a \u00e9crire la fen\u00eatre principale qui affichera \u00e0 l’utisateur l’avanc\u00e9e de notre traitement.<\/p>\n
QProgressBar et QThread.<\/h2>\n#ifndef MAINWINDOW_H\r\n#define MAINWINDOW_H\r\n\r\n#include <QtGui\/QMainWindow>\r\n#include <QProgressBar>\r\n#include <QDockWidget>\r\n#include \"thread.h\"\r\nnamespace<\/b> Ui\r\n{\r\n class<\/b> MainWindow;\r\n}\r\n\r\nclass<\/b> MainWindow : public<\/b> QMainWindow\r\n{\r\n Q_OBJECT<\/b>\r\n\r\npublic<\/b>:\r\n MainWindow(QWidget *parent = 0);\r\n ~MainWindow();\r\n\r\nprivate<\/b>:\r\n Ui::MainWindow *ui;\r\n QProgressBar *workinprogress;\r\n QDockWidget *Progressdock;\r\n Thread* myThread;\r\n};\r\n\r\n#endif \/\/ MAINWINDOW_H<\/i>\r\n\r\n<\/pre>\nRien d’original, une mainwindow avec juste trois membres. Une QProgressBar qui affichera la progression.
\nUn DockWidget pour afficher la progesse bar, je ne l’ai pas impl\u00e9ment\u00e9 dans cet exemple mais il peut \u00eatre amusant d’afficher le dock quand une op\u00e9ration est en cours et la cacher quand c’est fini. Le dernier membre est une instance de notre classe Thread.<\/p>\n
#include \"mainwindow.h\"\r\n#include \"ui_mainwindow.h\"\r\n#include \"wait.h\"\r\n\r\n\r\n\r\nMainWindow::MainWindow(QWidget *parent)\r\n : QMainWindow(parent), ui(new<\/b> Ui::MainWindow)\r\n{\r\n ui->setupUi(this<\/b>);\r\n workinprogress = new<\/b> QProgressBar;\r\n Progressdock = new<\/b> QDockWidget(tr(\"progress panel\"));\r\n workinprogress->setValue(0);\r\n Progressdock->setWidget(workinprogress);\r\n Progressdock->setAllowedAreas(Qt::BottomDockWidgetArea);\r\n addDockWidget(Qt::BottomDockWidgetArea,Progressdock);\r\n WAIT* mywait = new<\/b> WAIT();\r\n\r\n myThread = new<\/b> Thread(mywait,false<\/b>);\r\n connect<\/b>(mywait,SIGNAL<\/b>(Maximum(int)),workinprogress,SLOT<\/b>(setMaximum(int)));\r\n connect<\/b>(mywait,SIGNAL<\/b>(Minimum(int)),workinprogress,SLOT<\/b>(setMinimum(int)));\r\n connect<\/b>(mywait,SIGNAL<\/b>(valueChanged(int)),workinprogress,SLOT<\/b>(setValue(int)));\r\n\r\n connect<\/b>(ui->pushButton,SIGNAL<\/b>(clicked()),myThread,SLOT<\/b>(start()));\r\n\r\n}\r\n\r\nMainWindow::~MainWindow()\r\n{\r\n delete<\/b> ui;\r\n}\r\n<\/pre>\nNous initialisons la QProgressbar et le QDockwidget. En suite, je param\u00e8tre un peu nos deux instances. Je cr\u00e9e alors une instance de WAIT et j’initialise le thread avec en param\u00e8tre l’adresse de notre commande.
\nJe connecte maintenant les signaux de la commande au slot de la QProgressBar.
\nFinalement, je connecte le clique sur “pushButton” sur le d\u00e9marrage du Thread.
\nAinsi, \u00e0 chaque clique, il demarrera la commande wait.<\/p>\n
Aller plus loin<\/h2>\n
Il serait pr\u00e9f\u00e9rable de cr\u00e9er une instance de WAIT \u00e0 chaque clique et de l’ajouter dans une pile (dans la mainwindow). Cela est n\u00e9cessaire pour finir le design pattern command. En haut de la pile, se trouve la derni\u00e8re commande, si elle est annul\u00e9e alors il faut la d\u00e9piler et ex\u00e9cuter undo().<\/p>\n
![\"Capture](\"http:\/\/renaudguezennec.eu\/prog\/tutorial\/11\/Capture-3.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"