@JonnyQB Hi You declare it like Punkte * punkten; Then some place else you must do punkten = new Punkte(); ( not in .h) Often the constructor is a good place.

The problem was that my class inherited QGraphicsItem, not QObject, but I found another way to do what I wanted. From now on, I will use the new syntax. Thank you!

@oblivioncth said in Why does the const Object returned by QList::at() block access to instance methods?: Hey, going above and beyond! Thanks again. You're most welcome! I'm not completely ignorant in the ways of C++ though, I'm not 100% certain, but fairly confident that: Const 1) Ensures the returned value can't be modified, Yep. the use cases of which I'll admit I'm not really privy to. Use case 1: Allow the caller to read the data without creating a copy, AND Make sure the data is read-only If the returned reference is non-const, the caller will be able to directly modify the object's internal memory. This breaks encapsulation. Use case 2: Allow the function to be called in another const function. There's a const and a non-const version of QList::operator[](int): T & operator[](int i) const T & operator[](int i) const Version #1 allows the caller to modify the QList element. However, it cannot be called in a const function -- it will cause the error in your original post. Thus, version #2 is required for use in const functions. I know that its only really useful when dealing with user defined classes and returning by value reference (which is the case in your example) to prevent memory modification if desired. (Acknowledging your typo) Why would it be "only really useful when dealing with user defined classes"? Notice that QList::at() returns a const reference. I do remember seeing something about this being somewhat obsolete in C++ 11 (or was it 17) and forward, though I'm not sure why. Returning const references is defintiely not obsolete. You might be remembering move semantics, which is said to make passing parameters by const-reference obsolete: https://stackoverflow.com/questions/10231349/are-the-days-of-passing-const-stdstring-as-a-parameter-over Qt will not be making this change anytime soon though; this is too disruptive. Const 2) The pointer argument "arg" in that class is for the type "const MyOtherClass", i.e. a pointer to a constant value (value cannot) Yep, myfunc() cannot modify the MyOtherClass object. (In other words, it can only call const methods of the object) Const 3) Marks the pointer "arg" itself as pointer, so that the pointer itself also cannot be modified) Yep. This is not very useful IMHO, but it's part of the language. Const 4) Thanks to you, I now understand this means that the function does not modify the object instance that the function is being called on/from (i.e. cannot manipulate member variables). Great! Next, start thinking about the difference between logical const-ness and physical const-ness: https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-state Btw I do like a lot of the explanations on that site as they provide a lot of detail and examples, and I had never read the article for const. Agreed

@Nico1564 said in How to draw on Image loaded in a QGraphicsView: Yeah i know that this work but i need to draw with fonctions. I successed to do that but I don't want to have the GraphicsView at the beginning of the program, and i want to add draws like an Ellipse (and the image) when i click on buttons. These lines could just as well happen inside a button click QGraphicsEllipseItem* testItem = new QGraphicsEllipseItem(20,30,120,70,0); m_pScene->addItem(testItem); In that case, you would create an ellipse every time you pressed that button. I don't quite understand the "I don't want to have the GraphicsView at the beginning of the program" - maybe you could elaborate on that.

change progsettings result = Data.Process(); to auto result = Data.Process(); I'm trying to get the 2D array of QString. change: QString progsettings[50][2]; to std::array<std::array<QString,2>,50> progsettings; (you need #include <array>) QString Process(); to const std::array<std::array<QString,2>,50>& Process(); QString ReadProgData::Process() to const std::array<std::array<QString,2>,50>& ReadProgData::Process()

@Kalado said in Connect() uses wrong emitter object.: Look at some code: //A.h class task2 : public QWidget { Q_OBJECT public: task2(QWidget *parent = 0); ~task2(); protected: void mousePressEvent(QMouseEvent *event) override; signals: void myWidgetClicked(); //A.cpp void A::mousePressEvent(QMouseEvent *event){ /// use the respective classname emit myWidgetClicked(); } If ur using Classname as task2 , use void task2::mousePressEvent(QMouseEvent *event){ emit myWidgetClicked(); } Thanks,

@yuvaram If so, compile it with Network Download Example, which is officially available from Qt.

@Wieland Wow you are just killing it today for me aren't you? Haha. I'll judge which is best for me a give it a roll. Thanks a bunch (again)! EDIT: I ended up going for the event filter route and it works beautifully. Other than the exact syntax the approach also feels pretty intuitive which I like.

Hi Normally you use signals and slots. Like when TcpServer got a connection it calls a slot in mainwindow. You set it up with connect. http://doc.qt.io/qt-5/signalsandslots.html http://www.bogotobogo.com/Qt/Qt5_QTcpServer_Client_Server.php http://www.bogotobogo.com/Qt/Qt5_QTcpServer_Multithreaded_Client_Server.php

@fortyff said in Undefined referance to class::function: There are the same errors occured in the "esimplelabel.cpp" file, but I didn't write down here, since it'll consume too much place. Make sure you have all virtual functions that are declared defined. While a declaration of a regular function without a definition is perfectly valid (until it's called), that's not true for virtual methods.

Just adding a header file here won't help much and you are doing it the wrong way around. Why should your EmployeeInfo class know anything from MainWindow ? That's only going to create a tight coupling and the time you'll want to change MainWindow for something else, you'll also have to change EmployeeInfo. If you are going to show EmployeeInfo from MainWindow, add setters to EmployeeInfo that you'll use to update its content before showing it like already suggested by @mjsurette or use properties/signals and slots.

AFAIU, these are not really errors in the sense of validation. Your user forgot to e.g. check an option in a multiple choice question but that doesn't count as "wrong" like he tried to put an invalid value. Thus I don't see the need to modify Additem back from Review.

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();

Hi and welcome to devnet, What variable do you want to update ? Why do you think you need a thread for that ? On a side note, update is a QWidget non virtual slot so you can't use that name. In any case you should call labelTimr->setText("TIME :" + timeValue) to update the content of your QLabel.

@alex_malyu Thanks very much that's what I was missing. To get it working I removed the include for DifficultyAnalyser in the SokoGenerator header file #include "DifficultyAnalyser" I simply the following in the SokoGenerator header class DifficultyAnalyser; DifficultyAnalyser* diffAnalyser; I then included the DifficultyAnalyser header in the SokoGenerator cpp file, and created a new instance of it #include "difficultyanalyser.h" diffAnalyser = new DifficultyAnalyser; And in the header for DifficultyAnalyser I included SokoGenerator #include "SokoGenerator.h" Thanks for your help!

@JohanSolo Ah ok, so it is due to the organization of C++ not Qt, and like you said, the difference of a class instances and pointers. It has been long time since I've had to use C++ and I never did anything too advance with it other than a text-based adventure game. I generally am more focused on hardware oriented programing such as with C and Verilog, and MATLAB is the only more software (excluding Arduino interaction) oriented language I have decent experience with. Thank you for pointing out why there needs to be a difference. I wasn't familar with pointer usage in C++.

My apologies, I will create a new thread. Thanks for all your help! (and putting up with my stuff :) )

Lets forget for a moment about ctSettings for simplicity. A push button emits the signal clicked(). (If you need reaction on different button, you might need another signal) This means that to react on the click you need to connect slot of QObject derived class instance to this signal. Your MainWindow is such QObject derived class. So you can use it for such purpose. I assume it also has access to the button pointer (for example ui->pushButton) So now you need a slot. If writeSettings is a regular function just convert it to a slot. Now we need to connect signal to slot. In MainWindow constructor right after ui element are initialized (setuUi()?) add : bool ok = connect(pushButton, SIGNAL(clicked()), this, SIGNAL(writeSettings ())); Q_ASSERT( ok); Now writeSettings will be called when button is clicked and settings will be saved. About ctSettings. There is no need to use custom class at least for this purpose, but you can place all functionality in your custom class and use it if you prefer void MainWindow::writeSettings() { ctSettings s; s.writeSettings( ... ); } Now you will need to pass parameters to ctSettings ::writeSettings( ... ) This better not be pointer to ui, cause you will introduce dependency ctSettings on the ui class which will be changed dynamically during development. Better to limit such dependency to MainWIndow. ( This is why you did not want to have ctSettings class ) In this case you would pass pass individual control like: ctSettings s; s.writeSettings( const QCheckBox* checkBox1 ); For all other questions I would recommend C++ book. I can't explain what "private" is better than there. Just understand that as soon in the code you see variable of specific type (class) mentioned, it means compiler needs to know about this class already. Normally this means you have to include proper header file. (There is only one exception when incomplete class declaration is allowed, but book again will explain this much better than me). Regards, Alex

How are you setting up your model ?

Hi, Thank you both for your suggestions! As this project is intended for industrial purposes I think XML is a great solution. I followed some tutorials on how to use XML on Qt and managed to make it work (as well as understand) pretty well for what I intended to do. I'm leaving here the tutorials I followed in case someone stumbles upon this thread with the same problem: (I apologize if this is not allowed) https://www.youtube.com/watch?v=NXGE5XUrRSI https://www.youtube.com/watch?v=NzQwJdcdRKE I had to make some changes to my project but it's easy to understand. Thank you, once again!

From a design point of view it's not ugly. It's actually prettier. For example if you have a class Triangle or APieceOfRock they have conceptually no debugging or to string conversion notion whatsoever. Why should a triangle or a piece of rock know anything about strings or how to convert to them? Should it also convert to other data types like ACar or QWidget? Should you add a conversion method to them every time you introduce another type in your app? Making toSting() method in every class is pumping in it functionality that is out of their purpose scope and does not belong to that class. A separate utility function, detached from the class is actually a much cleaner solution that keeps responsibility separation.