For anyone coming across this thread, the answer is...

tl;dr: You need to add the runFullTrust capability.

With Qt 5, there was support for UWP apps. This made it possible for Windows apps to be delivered through the Microsoft Store. (This is how my app was built and delivered.)

Then Microsoft opened up the Microsoft Store for Win32 apps too; i.e. standard desktop apps. As a developer you have a choice of either packaging your own installer and delivering that through the Microsoft Store, or just your app, letting Microsoft Store handle installation. The latter option behaves more like the handling of a UWP app and Microsoft handles the code-signing certificate for you.

As a consequence, Qt decided to drop support for UWP as of Qt 6. This was done with no public notification to the Qt community 🤬, with just a message on the Qt development mailing list. I eventually found this out via a convoluted bug report.

What Qt themselves did not realise is that if you submit a Win32 app via the Microsoft Store, because it is a desktop app and does not sit nicely in a sandbox like a UWP app, you need to add the runFullTrust capability. If you don't do this, you get the weird behaviour of the application window opening in a separate window described above.

However be aware that when you add runFullTrust Microsoft will require you to justify why your app needs access to the whole Windows system. I was able to pass certification with a message along the lines of "My app is built with the Qt framework that only generates Win32 apps. My app does not operate outside the sandbox and behaves nicely."

One more gotcha if you're going this route. The path QStandardPaths::AppDataLocation was different for UWP apps than Win32 apps. The following only applies if you had a UWP app in Qt 5 and stored data there as the path will be wrong for your Win32 app in Qt 6. To fix this, I use the following: https://gist.github.com/paulmasri/75dcd3386a4e8eaf705058240ef547d1

@Christian-Ehrlicher

That would be ideal, but QMake was the system used when the project started. We're considering porting everything to CMake, but it looks like it's going to take some doing.

@Pl45m4
I tried to use the search function, but those seem to be good sources that I hadn't seen yet. I'll take a look at those right now. But I was able to find an answer on StackOverflow that I somehow missed until now:
https://stackoverflow.com/questions/32279193/cuda-win7-qt-creator-lnk1104-cannot-open-file-cuda-file-obj
I just copy-pasted it and it worked (after changing the version number from 7.0 to 12.1). Then I used the code I pasted above and it worked. Then I used a legit CUDA program and it worked. So I'm going to go through it line by line to understand why that .pro works. Thank you for the links!

@Jhonadam11 Get out of here with these AI generated responses.

I'd just flag their account, but I don't have the 2 rep required as this is my first post.

Well I feel a bit silly, but I thought I had tried that. Seems to work now though.

@nprobst said in Qt 6.2.4 Cross-Compile Windows Raspberry ARMV8:

on the host machine

On the host machine? How would that fix the issue in case of cross compiling? Are you sure you're really cross compiling?

Sure you can but that is a separate install. Microsoft does not allow third party installation.

As for the deployment, windeployqt is the cousin of macdeployqt. Using it will simplify the deployment process.

@RLocksley said in project.exe does not launch:

windeployqt project.exe

if that is the whole command you used, that you missed the --qmldir parameter
https://doc.qt.io/qt-5/windows-deployment.html

@DougyDrumz2 said in How do I make a QLabel Blink?:

The consensus is evidently to l hide and show a QLabel

Not my "consensus :) So far as I am aware, hiding can cause different layout redraw in at least some circumstances. I retain visibility but toggle foreground color to QColor(Qt::transparent) or toggle alpha color value between 255 (opaque) and 0 (transparent) on palette QPalette::setColor(QPalette::Text, colour).

Also, creating multiple QTimer::singleShot()s doesn't scale very well if you want to change the number of flashes or the interval between. Or of you have multiple labels to blink and you'd like them all to be "in sync". I use one regular repeating QTimer with a "countdown" and cancellation when it reaches 0.

Up to you on both of these.

@JonB sweet Jesus on the bike... this is the dumbest typo I ever made.

I am so embarrassed atm.

Thank you :D

@DanBar said in Problem with OpenSSL 1.1 after Qt update?:

If so, how can I make my application compatible with OpenSSL 1.1

It should be enough to just link to it during build and then make sure proper DLL files are in the same directory where your .exe is built. Which DLLs you need and what file names they are depends on compiler used and Open SSL version - sorry I don't remember them exactly, I use Windows only sporadically. If I recall correctly there used to be 2 DLLs in old versions, but nowadays it's a single file and it's called something like libssl-1_1-x64.dll.

or is there a way to switch back to OpenSSL 1.0 to test and see if this is the issue?

OpenSSL 1.0 has reached end of life a long time ago. DO NOT USE IT, it is a serious security risk at this point.

@VRonin said in I am Newbie trying to build Qt5.15.1 on Windows using MinGW, but got linking error:

That is an old post, the latest version of qcustomplot is compatible with all Qt 5.x versions as well as 6.0 (see https://www.qcustomplot.com/release/2.1.0fixed/changelog.txt)

You were right. I missed the latest qcustomplot update in March.
Thanks! :)

Adding to @JKSH, the qml option expects the path to the files in your project sources so it can parse them to pull all the required dependencies.

@san_qt_enthusisast I guess you should be using Java 8

I finally found a solution which seems to work in my case. I added the Qt.MSWindowsFixedSizeDialogHint window flag, which seems to fix the issue.

So below is the modified code:

ApplicationWindow { // common properties id: awMainForm width: 602 height: 728 flags: Qt.Window | Qt.FramelessWindowHint | Qt.MSWindowsFixedSizeDialogHint visible: true // form content isn't relevant ... }

@Ahsan-Niaz said in Releasing exe for 32 bit windows from a 64 bit windows qt creator:

Is it possible to add kits or whatever in my current qt creator.

Yes

As I already mentioned, I already have a project running perfectly on 64 bit windows. I want to create an exe that should run perfectly on 32 bit windows.
Please guide me with what steps I should follow. Thanks

Close Qt Creator Run MaintenanceTool.exe Select and install a 32-bit version of Qt from the MaintenanceTool Install a compatible 32-bit compiler If you're using MinGW, install it from the Qt installer If you're using MSVC, install it from Microsoft's website Open your project in Qt Creator and enable your 32-bit kit: https://doc.qt.io/qtcreator/creator-configuring-projects.html Build and deploy your application using your 32-bit kit

I don't want to reinstall qt and select the packages or kits because its a headache.

You don't need to reinstall Qt.

You must install a new version of Qt on top of your existing installation.

Recently, I had to run an exe released from 64bit windows qt creator for my client on his 32 bit windows.

The bitness of Qt Creator does not matter. What's important is the bitness of your kit. (Qt Creator can manage many versions of Qt, both 32-bit and 64-bit, at the same time)