General and Desktop

I found the problem... It was because i had 2 .hpp named the same way, one was with some other macros i used to code, and the second one was with the export macro alone.. They had both the same paths, so in the dll project it was let's say src/macros/defines.hpp, and in the app project where i import the dll it was the same, but i don't understand why when i was clicking on it, it was reffering me to the valid file which i wanted to use. Also, it worked for half a year, so i didn't bother to change it, probably it worked because the files didn't come in conflict, but since i changed a lot of paths in the dll project, it stopped working, and that's why i got the weird errors, the hpp was set to pragma once and the wrong file was applied, so the compiled treated it as some invalid syntax letters, still the macro in the editor was looking like it was applied, that's what fooled me.

@Christian-Ehrlicher Sry it's a list of data from database, so it might cannot be showned on this screen yet. Guess it's something wrong with reading the db file

@mpergand thank you. "PlainText" fix it

Backwards compatibility is what Qt does by allowing new Qt versions to compile code made for previous ones. Forward compatibility is what they do by being hesitant to introduce new APIs and methods. Say you write a program originally intended for use with Qt 5.12.11. Qt 5.15.2 is being backwards-compatible by not having any user-facing API changes major enough to inhibit compilation of their existing code, even if it's different under the hood. Qt 5.12.11 is forward-compatible in the same sense.

Because it's a linker error and not a compiler error. When you want to use hci_open_dev then you must also link against the appropriate library which should be the bluetooth library according e.g http://docs.cubieboard.org/tutorials/common/development/bluez_programming

@JonB Thank you. Now it's more clear to me.

@J-Hilk said in returning empty std::string when converting a QString with a path to an std::string using toStdString: sampleName.append(QDateTime::currentDateTime().toString("dd.MM.yyyy hh:mm:ss")); thanks a lot, much appreciated sir.

Three questions to close the thread: For the googlers out there I assume this applies to QStandardItemModel and QStandardItemModel subclasses as well right? Does the order of the moveToThread() and signal/slot passing to main GUI thread matter? I'm guessing the moveToThread() call should come first so the main GUI thread doesn't get scheduled before the moveToThread() call and use the model before it's thread affinity changes. Can I have your phone number @Christian-Ehrlicher in case Freddy Krueger knocks on my door? :)

I think you should bring this to the bug report system. Don't forget to add the analysis you did here.

You are asking for the header to be always visible, but does it need to show the whole range ? By the way, could you provide a minimal compilable example so that it's possible to test/validate the behaviour ?

@VoLinhTruc I do not use "auto connection from Designer", but so far as I am aware that works by naming the slots correspondingly to the signals, and then having a single call in the source code to void QMetaObject::connectSlotsByName(QObject *object). See https://doc.qt.io/qt-5/qobject.html#auto-connection and https://doc.qt.io/qt-5/designer-using-a-ui-file.html#automatic-connections. This means there will nothing in the .ui file for the connection, it will be done by name during initialisation of the designed widget.

If memory serves well, the version with a QString parameter is geared toward declaring aliases.

As I suggested, check the librairies that are loaded when running on the command line. You can also use a software line heaptrack to get some insight about what is happening within your application.

Reading the documentation again, I think you are correct. Then the next choice would be to put your custom scrollbar in a layout next to your QTableView.

Hi, That's were begin/endInsertItems comes to play. And their friends when removing rows.

@UvQtcYZJuD7J5VW7 said in Dependencies missing after DLL compilation: Unfortunately, LabView is not very talkative. This is the only error message I get. I have already recreated the node. Ah, check the dependencies of the DLLs that you deployed. For example, libgcc_s_dw2-1.dll depends on other DLLs too. Otherwise I could programming the entire program in Qt and so I will not have the need to use a DLL. If you can do everything in 1 language, that makes life a lot easier.

@VS-IK said in Inheritance and signals: //prints 111 instead of expected 222 That's because Api::foo() is not virtual. You can't override it.