@Chris-Kawa Just wanted to come full circle on this. What I've ended up doing is I have a StationController class which is injected with a StateCommander class. The Station controller then builds the state machine internally and connects to the concrete StateCommander's signals to be used for transitions. The state commander can be a UiCommander or a CLICommander etc. The base StateCommander class has methods such as LoadProduct which the UiCommander can override if need be, but the base class will just emit a RequestProductLoad signal. When the Commander is passed to the StationController, the StationController registers for the Commanders signals. So the UiCommander could contain a reference to the Ui components it needs, but a different commander wouldn't need to know anything about the UI. In this case I have a UiCommander which forwards button clicks signals to the generic signals the StationController is connected to. The state functionality remains static and is not coupled to a UI at all, but instead is coupled to just an abstract StateCommander. I had come across this example and really didn't like it because the states were so tightly coupled to the UI. The states take a Scene as an input and I knew I didn't want my states taking in UI components. By delegating the triggers to my StateCommander class, the state machine has no knowledge of whether the system is headless or not and the states can transition along just fine. I then have a UiController which contains the main window and it registers for events from my StationController and can update the MainWindow accordingly by calling main_window->setPage(page); The main window is just dumb and displays whatever the controller tells it to. I really like the decoupling but one thing I'm not a huge fan of is that the state is driven by a single Commander object, and if the station gets more and more complex, I will have to keep cramming functionality into that single interface. But, I think that's what you eluded to in the post I'm replying to, and I can live with that for now.

Hi, Why not use QChartView::setChart ? What you currently do is just replacing the object pointed by ui->diceView by a different one, but that is all.

Javascript abstracts the concept of pointers. Data is only ever passed around by reference. It is usually safer, since memory management is handled automatically and you can be sure an object equals another object if they are compared. If you need to compare objects to see if they are identical, you may have better luck creating a "compare" method that directly compares primitive attributes (strings can be compared directly, for instance). Hope this helps, sorry I can't provide a more specific implementation suggestion. Too many details to focus on at once.

@Christian-Ehrlicher Thanks! That saves a lot of trouble for me :)

@raven-worx @mrjj @Wieland @Pablo-J-Rogina Thank you guys ! It worked perfectly. I'm now able to read and write a XML file and load items to my drawing. Thank you again Happy coding !

Thanks guys for replies, generally my app isn't well designed because it's for education purpose. Anyway thank you very much.

Hi Just a note first Having class SerialPort : public QObject and then QSerialPort *serialPort; Where only diffence is capital S to the main class is just confusing. anyway, why is the issue with settings(new SettingsDialog()), did you declare it as void settings(SettingsDialog *mydialog) Im not sure what you dont understand. To use a pointer to a class in another class, you simply give the pointer to the other class and it can use it class B {}; class A { B* mykeptBpointer; setB(B* myb) { mykeptBpointer = myb; } void DoB { mykeptBpointer->xxxx(); }; A mya; B* myb = new B; mya.setB(b); oh, is settings(new SettingsDialog()) rather settings = new SettingsDialog();

@alex_malyu The original post is some 2 months old. So I wrote a whole lot of a post in reply to the original question ... well didn't my ears burn, when I noticed the post time ... I felt like a complete idiot. :)

@reezeus said: Is it a good practice to use QThreadPool even if I have only one thread? I've never used QThreadPool but I can imagine that it eases scaling if you do so... The day you want to increase the number of threads, simply have a bigger pool. On the other hand if you know that one thread is what you need and will continue to need, QThread seems more reasonable IMHO.

@SGaist Thank you mate, that clears it up a lot! EDIT: Is there a way for me to know when I should free something? Or will it just come by practice?

@Afterwork said: I recreate them every time. Are there better way ? If they change then there's no way around it but if they're the same every frame then it's a waste of time. Generate the list once, store it as a class member and just expose them by reference e.g. //split that to .h and .cpp of course class GameWidget : public QWidget { Q_OBJECT public: GameWidget(QWidget* parent = nullptr) : QWidget(parent) { generateMyListOfObjects(); } const QVector<Object>& objects() const { return objects_; } private: void generateMyListOfObjects() { //fill the objects vector here } QVector<Object> objects_; }; And how i can connect the slot of differents objects to built-in timer of QWidget ? You don't. As I said - reimplement the timerEvent method. It will be called every time the timer times out. You can call some methods directly in it or emit a custom signal if you'd like.

Yes that was it. You slot looks good. For that second task you can use QSignalMapper)