Language Bindings

Hi, and welcome! @joeren said in Integration of QML and C++: The application that will publish the interface onto the module is called G2Link and will only push QML files. This sounds like a non-standard setup. I had a quick look at their website, but I can't see how to program their device using C++ at all. Your best bet is to contact tech support at Reach Tech.

At the beginning of times, creating a GUI, be it on Windows or Linux, was something that wasn't easy to learn nor do and was not reusable at all. Qt was created to make the life of developers way easier as well as provide a framework that allows you to write your code once and then build it on a per platform basis. If you want another example, try to show an OpenGL window using native APIs vs doing with Qt. Qt is: simplicity elegance cross platform

I figured it out. Qt Remote Objects

Something new for this topic: QML/HTML Browser based on QT and Chrome. Support most of QML features like 2D, 3D, Charts, Multimedia and other stuff. https://github.com/Toorion/qml-browser

@Golgotho what is the error left ?

Sorry for this question. Jakarta has a lot functionality but it's for web development. Can I use Qt for web development?

Hi @katang, and welcome! Conan support has been discontinued, unfortunately: https://www.qt.io/blog/conan-package-manager-pilot-to-end-in-december

@JonB said in Create a method that takes in a sorted array of integers and returns a sorted array of the same integers.: My loop only runs while (i < j). I was too concentrated on the loop body, so I overlooked that. You are right!

Thank you Chris Kawa for your explanation. It's all I need to know.

In the compilation output the error is displayed as follow : 16:01:10: Start: "C:\Qt\Tools\mingw810_32\bin\mingw32-make.exe" -j8 C:/Qt/Tools/mingw810_32/bin/mingw32-make -f Makefile.Debug mingw32-make[1]: Directory Entry 'C:/Users/operateur/Documents/CB/WD_V5-masterv2' mingw32-make[1]: Nothing to do for 'first'. mingw32-make[1]: Leaving the directory 'C:/Users/operateur/Documents/CB/WD_V5-masterv2'

I am new in QT using C++ 98 It's almost 2023. It's time to move on :) As for the code - it's kinda all over the place. You're just iterating over some widgets. Why do you even need a signal mapper here? Especially since you map those widget to themselves? That doesn't make sense. find_child will return nullptr if it couldn't find anything. You're not checking that so you're probably getting nullptr and then trying to call btn->setStyleSheet on it. That will crash. Those buttons don't seem to be children of the signal mapper. At least there's no code here that would make them that. Your signal mapper doesn't have any children here, so find_child won't find anything and will return nullptr. You should call find_child on the actual parent of those buttons. In any case, find_child operates on object names, not variable names. Are these widgets actually named with setObjectName()? If not then find_child will not find them and return nullptr.

@withwind You need to have something like target_link_libraries(demoPing libPing...

@All Compared to an auto- connection writing a manual connection requires much more time and is more difficult to debug (exp. finding a particular connection in the source – The Goto slot… helps finding the location in the source). In this relatively large project it would take more than a month to repair all connections. I personally like these kinds of automatisms. Therefore I did some further analysis. First of all the auto-connections are only non reliable in terms of understanding what is going on. But the reported issue here is 100% reproducible. In fact the moc is not guilty at all and compiles correctly as the dispatcher code being produced by the moc has all the required calls: void MainWindow::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a) { if (_c == QMetaObject::InvokeMetaMethod) { MainWindow *_t = static_cast<MainWindow *>(_o); switch (_id) { ... case 35: _t->on_firstToolButton_clicked(); break; case 36: _t->on_prevToolButton_clicked(); break; case 37: _t->on_nextToolButton_clicked(); break; case 38: _t->on_lastToolButton_clicked(); break; case 39: _t→on_navigationLabel_linkH … This dispatcher method is called from another method int MainWindow::qt_metacall(QMetaObject::Call _c, int _id, void **_a) { … } and that one is called from a code section only displayed in assembly code. Assuming, that the _id for the dispatcher might be wrong I added a breakpoint to check, but while for all other buttons this call is executed, pressing the prev and next button this metacall method not even reached. As it tends to be reproducible I analysed the source files and with the help of GIT I figured out, that the only difference is in the MainWindow.ui: ... 1968 1968 <property name="locale"> 1969 1969 <locale language="English" country="UnitedStates"/> 1970 1970 </property> 1971 <zorder>toolWidget</zorder> 1972 1971 </widget> 1973 1972 <widget class="GraphicsWidget" name="recentPage"> 1974 1973 <property name="locale"> ... )* The first two columns are showing the line numbers as shown with GIT before/after Somehow the designer added the <zorder> key somewhen before yesterday, and re-assigning the slots was removing this line again. I have to add that the toolWidget is a container with a QGridLayout for all my buttons (about a dozen more) used to fade in and out the buttons simultaneously. For me it looks like that auto-connections can safely be used, unless a <zorder> key is present in the .ui file. So the remaining questions are: What did the designer cause to add the <zorder> key? Why only 2 QToolbutton were affected, but all others are working Ok?

@dobiz22 Just that it is better "style" to access via getters & setters. Hides some of the internals, allows a bit of extra code to be put into the getter/setter if required (e.g. validation), you can place a debugger breakpoint on them, that sort of thing.