General and Desktop

Please don't post images but source code which can be copied wrt your problem - Pair *m_pair[10] is a pointer to an array and when you have to initialize it before you use it. But I don't see any reason that this must be a pointer at all a c array should be used here instead e.g. std::array<> why the array is bound to exact 10 elements and you don't do any bounds checking at all. Use e.g std::vector<> what the class dictionary should do at all - either use a std::map<QString, QString> (or QMap or QHash) or directly the Qt translation system to translate your strings.

I just "discovered" this QT object / class or whatever does not recognize that Bluetooth has been turned off in OS - and emit SIGNAL "discovery finished"!! Furthermore - there appears to have no code to emit "errors". There are multitude of source code for this particular class . I am going to clone the most recent and hopefully more completed then the example is using. What a waste of time.... I appreciate all contribution posted, . however ,unless you can help me to identify most compete QBluetoothServiceDiscoveryAgent, consider this closed .

Hi, @kshegunov said in migration to cmake results in corrupt binaries: Qt's cmake files are no less complicated than the qmake project files, because there's a lot of pre, post and mid build tools that must be run so you can have a smooth experience as a user developer. Agree completely. ... and I guess it will stil take a while until using cmake will be that comfortable as qmake was/is. @kshegunov said in migration to cmake results in corrupt binaries: I'm not convinced that not knowing the build system well enough should give you confidence to make bold statements that it can't do things or doesn't work. I do not want to be misunderstood - the bold statements were not bold to increase their truth content, but so that it is also read by people who only skim texts and then write answers that do not fit the question at all. If that came across wrong, then I'm sorry. I enjoyed the exchange with you (personally) very much

@QtTester said in Draw QImage in QOpenGLWidget: I never thought you can use QPainter in ::paintGL(), that's a new idea. have you compared the CPU usage with ::paintEvent() ? There's no paintEvent with OpenGL widget, or specifically you shouldn't mess with it unless you want to break it. paintEvent is going to call the paintGL whenever it's ready for you to issue the draw commands or w/e. As for the CPU usage it probably is comparable. Note: please don't do the "stand up zombie" without a good reason. I really doubt the OP will be back to answer you.

@JonB Yes ! and my problem is solved thank you @posktomten

Since you fail to share what you are actually putting in your PRO file we are left to guess what you are trying to achieve, and how you have managed to break it. I guess that you are attempting to disable the normal state of affairs, where the compiler is directed to issue every possible warning. Observations: The correct way to disable (almost) all warnings is: CONFIG += warn_off (docs). You should not need to disable warnings. Read the warnings, understand why there is a warning, and address it in your code. The compiler writers are more aware of what is a risk to correct operation of your code than either you or I. The QMAKE_* variables are generally automatically managed and rarely need direct intervention.

@SGaist Thanks for that info.

Hi, You create a QImage out of an OpenCV Mat object. The constructor you use for that explicitly does not copy the data from the Mat object. This is what the warning is all about. It is your job to ensure that the Mat object lifetime is longer than the one of of your QImage. Or you should explicitly trigger a copy of the QImage object when adding it to your array. What happens is that when you do your concurrent call is that Mat object that used went out of scope and thus the QImage internal structure is now pointing to invalid data.

Unless you put the Qt parts behind a private implementation your users will have to link against Qt as well as your library.

Hi, You can use the QGraphicsWidget class for that.

Hi, No, that's the goal of final. The real question here is why are you using the same property name for something that returns a different type ? The return type is not part of a method signature so in any case the getter cannot be "overridden".

@Christian-Ehrlicher , thank you: QAbstractButton* pobjMale(cpobjButtonGroup->findChild<QAbstractButton*>("Male"));

@Ketan__Patel__0011 said in QGraphicsItem And QGraphicsScene: mousePressEvent Basic c++ - if you override a function and also want the functionality of the base class you should also call the base class implementation of this function.

@Dan203 said in Member variables vs new?: @kshegunov the biggest issue is that some classes take ownership of objects when you pass them to one of their functions, which they then try to delete when they're destroyed. Some do not. It's not always clear when this is happening. Yes, that's why you must be careful. The documentation indicates ownership transfer, which is almost always for widget based types. If that should happen the ownership acquiring object must outlive the transferred object for stack allocations to function properly. That's why you see so much heap allocations in fact, because it isn't always trivial or convenient to ensure the above.