General and Desktop

This bug seems to have not been fixed in Qt 6.10. Have you found a solution?

@JonB said in Launch telnet from Qt GUI application: @Christian-Ehrlicher said in Launch telnet from Qt GUI application: and don't use QProcess::startDetached() if you want to interact with your application Oh, really?? That's the whole point of this function - fire and forget https://doc.qt.io/qt-6/qprocess.html#startDetached

@SimonSchroeder The following code: #include <QApplication> #include <QBoxLayout> #include <QDialog> #include <QPushButton> int main(int argc, char *argv[]) { QApplication a(argc, argv); QDialog dlg1; dlg1.setWindowTitle("dlg1"); dlg1.setLayout(new QVBoxLayout()); QPushButton *button = new QPushButton("Click"); dlg1.layout()->addWidget(button); QObject::connect(button, &QPushButton::clicked, &dlg1, [&]() { QDialog dlg2(&dlg1); dlg1.setWindowTitle("dlg2"); dlg1.hide(); dlg2.exec(); dlg1.show(); // nested event loop fail! }); dlg1.exec(); return a.exec(); } works fine for me. Ubuntu 24.04, Qt 6.4.2. I press the button, see the second dialog, close it, and the first dialog reappears. I can remove &dlg1 from being the argument to dlg2's constructor and it still works. In what significant way does your situation differ from this?

You're welcome! @kaixoo said in DragHandler::onDragChanged not reporting continously: I'm also looking to register when the user clicks the middle mouse button + drags their mouse. DragHandler only registers events from the left click Set your acceptedButtons: https://doc.qt.io/qt-6/qml-qtquick-draghandler.html#acceptedButtons-prop I see now that handlerPoint has no signals though, how am I supposed to signal when the position has changed? handlerPoint is a value type, like date or string. The string doesn't emit a signal either when a character gets modified. Rather, the whole value gets updated. Putting these together: DragHandler { acceptedButtons: Qt.MiddleButton onCentroidChanged: { if (active) console.log("Centroid moved to", centroid.position) } }

Basically, the other answers already contain all of my thoughts. But, since I've been mentioned I'll still chime in. In a single-threaded context I can just call functions and that's fine. In a multi-threaded context when I want to call functions of an object that lives in a different thread (especially if you want to call GUI functions in Qt) invokeMethod() is the only easy way I know of. Sure, you can properly set up a signal. I personally don't see the point in having a signal (which I then need to connect) if it is called from just a single place in the code. First, I have to come up with an appropriate name for the signal, and second, I'll have a long list of signals in the class declaration that are of no interest to any outsider. The use case of of using this to call functions belonging to a GUI thread is so pervasive that I have a header-only library that (among other things) has a function guiThread(...) (https://github.com/SimonSchroeder/QtThreadHelper) to easily place calls into the GUI thread from other threads. From the recent discussion in this forum I have also learned that invokeMethod() takes a connection type as argument. I guess, then my function guiThreadMaybe() is not necessary, as the default is the AutoConnection which will do already a direct call if it is from the same thread (the 'maybe' part explicitly checks for that). Outside of multi-threading I only see a single use case for invokeMethod(): If I don't want to immediately execute that function, but put it in the event queue to be executed at a later point. I guess this is a valid use case, but not one I encounter often. In many cases, the suggested solution is a single shot timer with a timeout of 0ms. In addition to putting this call into the event loop, it will also only execute once the event loop is otherwise idle. @JonB said in Relevance of invokeMethod() in multithreaded programs: I didn't see why there is a particular mention here of separate threads. It wasn't mentioned in the original post, but later: @Christian-Ehrlicher said in Show a QMessage box from the context of a function defined outside mainwindow.cpp: One problem with a simple callback will arise when you run the solver in a different thread. "invokeMethod() is also my general solution if I'm multithreaded" needs to be read in the context of the original discussion: It was specifically about calling GUI functions. If we combine that with multithreading, invokeMethod() is the (hard-to-find) obvious solution.

@lukester88 said in Show a QMessage box from the context of a function defined outside mainwindow.cpp: A major theme I have in my code is keeping UI code and solver code completely separate, and I would like to continue that trend with this specific task. My question is - how can I make these functions show a message box to the user when the function is executed? For example, when the user presses the button, and the function executes, if it exceeds the maximum number of iterations, the function should finish executing, and then a message box should show up warning the user that the function failed to converge. Furthermore, how can I implement such a thing without using UI code in the file with the solver source code? Make your solver return information about whether it converged on an answer or not: struct SolverResult { double finalValue; bool converged; }; Then, do extra checks when processing the result. If your result-processing code currently looks like this... void MainWindow::onSolverFinished(double finalValue) { this->doSomethingWith(finalValue); } ...now you can do extra checks: void MainWindow::onSolverFinished(const SolverResult &result) { if (result.converged) { // Yay, we found a solution! this->doSomethingWith(result.finalValue); } else { QMessageBox::warning(this, "No solution found", QStringLiteral("Failed to converge on a solution within %1 iterations").arg(m_maxIterations) ); } } Alternatively, you could adopt a convention like "Return NaN if it fails to converge", and show the QMessageBox inside if (qIsNan(finalValue))

It is not so easy to decipher what the actual problem is. However, here is what I observe. We start with the following string: "123\n456\n789" If you just want to delete something from the string, you would replace it with an empty string. So, s.replace("456", ""); would yield "123\n\n789" This means, that this would print an empty line between 123 and 789. However, if you do s.replace("456", "\b"); you'll get "123\n\b\n789" I guess that like most people here I haven't ever used \b myself. Not all implementations that print out strings to the console (or wherever) might have an appropriate implementation of \b. Hence, this might vary. One possible implementation is that \b will indead delete the previous character when printed. In this case \n would be removed. This would result in the same output as "123\n789" However, another implementation might print line by line. So, when \b is encountered a new line has already begun. And on the new line there is nothing to delete. The command line is not a text editor where there is a document behind it and everything is rerendered when you change something. On the same line the implementation is quite simple: go back one character and replace it with blank (but keep the cursor at the same position). However, if the command line has to go back one line, it does not have the information stored where the previous line ended. It is quite impossible (without buffering) to go back to the previous line. After a new line you (most likely) have committed to what is printed on the screen (in most implementations). Note that you'll insert \b into the string. This does not delete the previous character inside the string. The string itself is just bytes and contains what you put in it. If you want to delete the full line containing 456, you should write s.replace("456\n", "");

Thanks @SGaist. I agree that there can always be unknown unknowns in the deployments. I wanted to confirm that there are no obvious issues. I'll go ahead with the testing of this.

@dviktor With the version shipped with debian trixie 11.8.6-MariaDB-0+deb13u1 , it works properly

Not three wrong ones, each has its use 😅 That said, you learned stuff on the way which are valuable You're welcome !

@Gijs-Groote said in Future of non C++ backend languages and Qt frontend: What future plans does Qt group have with QtWidgets? I guess that most developers in this forum feel like QWidgets is mostly (but not fully) abandoned project. QML is continuously developed further, but QWidgets is stagnating. This might be related that for desktop applications you can use the open source license (only few are paying for a commercial license). QML is important for embedded, automotive, and mobile. For most (or all?) of these areas you have to buy licenses. So, this is where the money is. If you are a larger company and have dedicated designers, I would claim that QML is the better option (many designers can easily edit the design in QML or even use standard design tools). Few designers will be able to edit C++ code (in the case of QWidgets) to change the design.

@drmhkelley hi, Check that you did not disable Shadow builds in Qt Creator.

@SGaist said in Assert in QTabWidgwt: It's not your code that is doubted, it is whether there is a mix between your application being built in release mode but using debug libraries when running or vice versa. Can you check whether you are using the libraries matching your application build type ? I use CMAKE to manage the dependencies, and do not add any lib manually. This issue just happened in Debug mode. I check (by my IDE , visual studio 2026 ) all libs used in my project , all of them are Debug mode. And i also check the libs in "Install directory", there is no problem either. I start the exe ( double click ) in install directory, it also has runtime crash with the message box "Debug error! xxx.exe abort() has been called ".

@Chris-Kawa said in Creator cannot set layout on QMainWindow::centralWidget: Layout options are now available on the toolbar "Toolbar"? Wazzat? This tiny thing with pictures I have to guess what they mean? [image: e01ac1ba-f8e9-41bc-8756-06ece4f6f58e.png] Never noticed it, never used it! :) Words mean something to me ["a picture is worth a thousand words" -> "two words are worth an icon":) ]). If you can select an object and there are actions you can perform on it I am used to right-click context menu with what I can do. Anyway I agree that if you are on contextMenu this toolbar is the one and only way you can add a layout. (I have just found that main menu Tools > Form Editor also works like the toolbar on contextMenu, so that's another way.) If you want the corresponding right-click menu option you have to go select the Main Window node instead. My searches show I am not alone in not having a clue this is how it works. The options are enabled only after you add a child. Complained about that 10 years ago. Totally unintuitive, and again do a search to find how many others have no idea this is how it works. When designing a hierarchy of widgets I expect to: put the top-level widget down, set its desired layout, add child widgets, and repeat. Why you have to know to put a child first and only then go back and you can now set a layout is beyond me. 16 major release version numbers on from when I started with Creator it still has not addressed simple UI issues (e.g. just want to copy & paste a widget like in other Designers...?)....

Hi, AFAIK, you need to build it yourself.

Update: The actual IFW 4.11 provides a Mach-O Version of the Maintanancetool. But because Apples codesigning is broken on the dynamically created maintanancetool you need to create your own prior and add this precompiled and notarised as a separate component to the installer packages. Use this component script to replace the "qt created " maintanance tool with your own version at the final end. function Component() { component.ifwVersion = installer.value("FrameworkVersion"); installer.installationStarted.connect(this, Component.prototype.onInstallationStarted); } Component.prototype.onInstallationStarted = function() { if (component.updateRequested() || component.installationRequested()) { if (installer.value("os") == "mac") { component.installerbaseBinaryPath = "@TargetDir@/tmpMaintenanceToolApp/maintenancetool.app"; installer.setInstallerBaseBinary(component.installerbaseBinaryPath); } } } Component.prototype.createOperationsForArchive = function(archive) { // IFW versions 4.8.1 onwards supports extracting the maintenance tool to a folder. // It is a good practice to extract the maintenance tool to a folder in macOs, so // it won't interfere the current running maintenance tool. As the last step of the // installation, IFW will move the maintenance tool to the root of the installation. // Windows is using deferred update for the maintenance tool, and Linux inode. if (installer.versionMatches(component.ifwVersion, "<4.8.0") || (installer.value("os") != "mac")) component.createOperationsForArchive(archive) else component.addOperation("Extract", archive, "@TargetDir@/tmpMaintenanceToolApp"); }

how about instantiating one QSqlQueryModel per DB (each keeps its own connection/cursor, untouched) and combine them at the view layer using QConcatenateTablesProxyModel instead?