General and Desktop

Thanks for the reply! Yes, I agree this really seems to be a tvirt.vir issue, not Qt. That's why I wrote a standalone C program (outside Qt) to test the pipe communication. I’ve already tried: Sending the message DO#0#1 to \\.\pipe\\tubotest Triggering the EventoEnviar event after writing Still, nothing changes on the simulator side, and the input value shown in my DAQ console remains 0. I do have some documentation, and it says tvirt.vir listens for specific commands and events, but I’ll try to confirm exactly what sequence it expects. Thanks again. I’ll keep testing with the C version for now.

@JulsPower That does look more reasonable, i wasn't sure what the MS docs were telling you to do. Which implies you were in the Another possibility is that the issue has nothing to do with Qt or deployment but rather is a "bug" which only happens to show up in certain environments or circumstances. Such as a memory access issue. I had a quick glance at your WTSEnumerateSessionsExA() and it seemed OK to me, but you might want to try it standalone without any Qt stuff to make sure that works across environments. situation! The Qt and deployment changes simply showed or masked the problem. But you have still learnt what you should do to e.g. deploy to another machine, or be sure it works on yours outside of the Creator development environment which should be useful :)

@aha_1980 said in How to switch off specific warnings in Qt Creator: @DiBosco Have you already seen https://stackoverflow.com/questions/22129383/removing-unused-parameters-warning-in-qtcreator ? For your case, it would be: QMAKE_CXXFLAGS_WARN_ON += -Wno-deprecated-copy Regards Ah, yes I had seen that. The English in the most upticked reply just made me go "What?". Just could not understand what they were saying, but I had tried: QMAKE_CXXFLAGS_WARN_ON += -Wdeprecated-copy Thinking why on earth would putting the warning on make it disappear, but out of desperation I gave it a go. Had I realised it needed -Wno-deprecated-copy, not -Wdeprecated-copy I'd've been fine hours ago. Many thanks for that, now doing just what I want. Also @JonB Thanks for your help too.

@hskoglund said in Qt6 and QT_ENABLE_HIGHDPI_SCALING: If you right-click on the .exe file, select Properties and in the Compability tab click the "Change high DPI settings" button, does any setting in that dialog box help the faulty scaling after QApplication is instantiated? Thanks for the suggestion but I think those settings effectively override the manifest (so startup only) and indeed I can change the setting on an exe so that it "supports" High DPI even when it doesn't and start it up and you can see scaling issues. Reverting it while it's running makes no difference. However, this is now moot as I decided to suck it up and change the legacy code to check for and support the system scaling. We have a fair number of these MFC apps and on some this will be a lot more work than others. This one is not too bad as the main client window is written using our Direct2D library which already supports such scaling. As expected Windows common controls support this out of the box and weirdly all our MFC dialogs also display scaled with the only apparent issue being the font text display appearing "thin" and somewhat faded. Not enough of a problem to care about.

I think it is necessary to port the Qt5 service library to Qt6. I haven't did it because the qt6 already built framework can't run on Windows 2016 machines and I have a lot of them. Qt6 requires Windows 10. So, up to now, I'm using Qt5.

@jsulm said in System tray crash in macOS 16: how is your question related to this thread? Forked now :)

@Axel-Spoerl, I only wanted to discuss it with them, but you've all answered everything I wanted to know. (I don't mean I was speaking on their behalf.) Thanks, all!

Just see here and here.

@Perdrix said in Size of QtWebEngine: Unfortunately litehtml won't work for me - I need function it doesn't provide :( That's pretty much the tradeoff. Chromium has All The Things you might need, but that means it has the disk usage of All The Things.

@Perdrix said in QProcess::terminate() or QProcess::close(): All well and good but that presumes that the process in question accepts input asking it nicely to close (probably on re-directed stdin). In this case the help display process doesn't support that. I've now changed to use start() instead of startDetached() Actually that's not entirely true. For a normal command line program it would terminate on its own, such as "ls, ps ax, df,...whatever", but in your case it's a little different. The POSIX way to tell a child to die gracefully is to send it a kill signal, which is different from using close/terminate. kill(pid, SIGTERM) kills a process, and can be trapped by the child to do cleanup. But in all fairness the QProcess::close() probably does that implicitly, whereas QProcess::terminate() is not "nice" about it.

@bogong said in Add resource file (*.qrc) to static library. How?: How to add *.qrc files to library and how to use it in the main project? You would use qt_add_resources() for *.qrc files: https://doc.qt.io/qt-6/qt-add-resources.html However, if your *.qml files are inside a *.qrc then you won't get the full benefits of qt_add_qml_module() (such as optimization via the Qt Quick Compiler: https://www.qt.io/blog/the-numbers-performance-benefits-of-the-new-qt-quick-compiler). It is better to move all your files out of the *.qrc, and directly into the qt_add_qml_module(): qt_add_qml_module(${A_NAME_TARGET} URI Library_v1 QML_FILES ATestQML.qml BTestQML.qml RESOURCES myimage.png myotherimage.png )

@EduardoQtDev said in CMake problem with Qt 6.10.0: Just in case someone wants to open a bug report. https://bugreports.qt.io/browse/QTBUG-137577 - Known, and already fixed it seems. You'll need to wait for beta2, or build from Git.

One other possible option that might also make your users happy: have a setting in your application that allows to set the path to ffmpeg so if they have a custom version they want to use, they can change for it. You can populate that value checking for known paths.

in fact you need two structures : one core structure containing all the data, called the model, and a UI component displaying the data from the model. It is bit more complex and time consuming to setup than an excel/libreoffice spreadsheet, but much more lightweight and offers you more control and more protection on how data are displayed or edited, which cells are editable. creating a view in TableView { id: tableView anchors.fill: parent // or whatever anchoring/positionning/layout you want model: yourTableModel // should be declared nearby } Please note that TableView on it's own doesn't provide horizontal and vertical headers, you have to add VerticalHeaderView and HorizontalHeaderView manually. https://doc.qt.io/qt-6/qml-qtquick-controls-verticalheaderview.html for the model, you have two options : either you subclass QAbstractTableModel, adding a QML_ELEMENT macro after Q_OBJECT, and declaring those source files in a qt_add_qml_module directive in CMakeLists.txt The TableView documentation provides a minimal example of a model that can be used in a QML view : https://doc.qt.io/qt-6/qml-qtquick-tableview.html or you can use the ListModel QML element if your model isn't much complex. Option one is usually advised for production. Option two is often used by UI dev to supply a sample model to work on the view itself.

https://download.qt.io/official_releases/qt/

The fact that Qt does not implement a direct method to generate QIODevice-like signals for stdin implies that doing so is difficult or impossible. The problem with using a separate QThread in the child to generate signals by blocking on sys.stdin.readline() is getting that QThread to exit. QThread.terminate() does not terminate that QThread until a line of input is received. All related answers ignore this problem. I was able to workaround this by having the parent process feeding the child's stdin send "exit\n", and have the child's stdin-reading QThread detect that line and call its QThread.exit().

@SGaist Thank you! This seems to work (well at least it compiles)! auto deepSkyStacker = DeepSkyStacker::instance(); connect(ui->help, &QLabel::linkActivated, deepSkyStacker, [=]() { deepSkyStacker->help(); }); David

I'm resurrecting this because I am facing the same issue. We are looking at Qt as a migration option from MFC (one of several). So I have VS Tools added to Visual Studio 2022. I have manually added the Qt "bits" to the relevant project file but I can't find a way of successfully adding this in to the Qt settings part for the project: CONFIG -= entrypoint I tried passing it on to qmake in the "Additional Command Arguments" but to no avail. There appears to be lots of things I could do with the "Qt Project Settings" within Visual Studio but if there's any documentation on this, I can't find it. TIA