I'm currently working on an app and I'm unable to set global stylesheet. Here's the code I've been trying:
QFile file(":/dark.qss");
file.open(QFile::ReadOnly | QFile::Text);
QTextStream stream(&file);
qApp->setStyleSheet(stream.readAll()); '''
and
QFile f(":/dark.qss");
if (!f.exists()) {
printf("Unable to set stylesheet, file not found\n");
}
else {
f.open(QFile::ReadOnly | QFile::Text);
QTextStream ts(&f);
qApp->setStyleSheet(ts.readAll());
}
For the first one I'm getting :
QIODevice::read \dark.qss device not open
and for the second one
Unable to set stylesheet, file not found
The second one used to work fine 2 weeks ago (build with msys2, mingw64, qt5.14.1.3), unfortunately, I had to reinstall mysys2 and since then this is not working anymore.
I tried to build using msys2 with all the packages I used 2 weeks ago (had to downgrade about 80 packages manually ) also straight from qt creator with no luck.
Any idea what might be the problem?
The issue has nothing to do with msys. The most obvious reason is an incorrect project setup. Please make sure dark.qss is added into the resource (qrc) file under "/" prefix and the qrc file is added into RESOURCES in the pro file.
Also, there is a bug in qmake not adding newly added resources into the app sometimes. A full rebuild might help in this situation.
It would be great if you paste both the qrc and pro file here. A full build log could be very helpful as well.
Maybe your .pro file is missing RESOURCES variable with .qrc file name.
You can also try to execute Clean and Run qmake on your project before building.
Related
I'm using SFML in Visual Studio 2015 to make a game that requires me to print text. I try to load fonts and keep getting an error that says "failed to create the font face". I've tried loading several different fonts and none of them work, and they are in the correct directory, which is the folder where my project is located.
This is literally all it is, and it doesn't work:
sf::Font font;
if (!font.loadFromFile("arial.ttf"))
return EXIT_FAILURE;
The ttf file for arial is in the same folder as the project itself, which is what seems to solve the problem for everyone else I find online who has the same issue. Any idea why the font still won't load?
The simple answer is, the file is not in your current working directory when you run your executable.
Try to put in a fully qualified filename. It will work.
Using Visual Studio, most likely this is the directory where your .vcxproj file resides.
If this does not work, you can find out what your current working directory is by checking this post for a generic way how to find out your current directory.
As a quick hack, you could just create a file when your program starts. Start once and check where the file gets created. This is the current directory.
I fixed with this:
sf::Font font;
if (!font.loadFromFile("../arial.ttf")){
return EXIT_FAILURE;
}
I'm using CLion on Ubuntu using SMFL also.
To add to this, I was experiencing this same error when I thought I'd had everything typed properly. What ultimately ended up being the issue was that I had written .tff for the font file rather than .ttf, which, once corrected, fixed the problem.
My TTF file had no permissions once extracted from its archive. Executing chmod 644 font.ttf fixed the problem.
I'm trying to include a SSL cert in the app deployment so we can connect to our server securely. I am able to add the files into our asset folder and our resources.qrc file and it works with debug deployment. However when I try to make a release build, it breaks and is unable to find the files.
I've ripped through the QT docs and SO, but everything I've tried has not worked.
Here is the excerpt from the .pro file:
`qmlFolder.source = qml
DEPLOYMENTFOLDERS += qmlFolder # comment for publishing
assetsFolder.source = assets
DEPLOYMENTFOLDERS += assetsFolder
# Add more folders to ship with the application here
QT += xml svg quick qml widgets
# resources.qrc
RESOURCES += resources.qrc # uncomment for publishing`
Here is my resources.qrc file:
<RCC>
<qresource prefix="/">
<file>qml</file>
<file>GandiStandardSSLCA2.crt</file>
<file>SSLcomDVCA_2.crt</file>
</qresource> </RCC>
Here is where I set the path: certPath = "://SSLcomDVCA_2.crt"; // Dev Cert
I got the path from right clicking the file. Again it works in a debug build, but not for release, so I believe it's not being packaged properly. Any hints or ideas how to proceed resolve this issue?
I've found the "issue" and the answer to my problem. Although I think the problem would be a QT bug or my understanding of string definition is wrong. I set the resource file called certs.qrc when I put the two certificates for dev and prod. I created the file definition and used the path I got by right clicking on the resource file and copying it's path. See below for the full definition of the SSL, hopefully this will serve as an example for QT SSL as well because I could barely find any of those either.
Here is my certs file without the 'RCC' header because it seems to break block quotes:
<qresource prefix="/certs">
<file>GandiStandardSSLCA2.crt</file>
<file>SSLcomDVCA_2.crt</file>
</qresource>
Below is the definition for that certificate file:
// SSL socket set up
QFile certFile(":/certs/GandiStandardSSLCA2.crt");
if(certFile.open(QIODevice::ReadOnly))
{
qDebug() << "File opened";
}
else {
qDebug() << "Boooo";
}
QSslCertificate cert(&certFile, QSsl::Pem);
forgotPwSocket = new QSslSocket(this);
forgotPwSocket->addCaCertificate(cert);
All this is currently functional. make sure you run qmake in order to get the resource files compiled.
So now, my explanation as to why I was having a problem. I was using a different deploy method before for the certs where I was deploying the entire assets folder. That works for Android by not iOS so I decided to go with qrc instead. While I was trying to implement the /assets folder deployment I was using an ifdef to define the string of the path depending on if it was iOS or Android. I removed the ifdef, and all my problems went away, it was now able to find the files at the path. The string is a member of my network object and I would define it at run time using the ifdef. During all my debugging, it was the correct path as shown in the inspector. Realizing that using the .qrc resource eliminated the need to define the path based on Android/iOS I hardcoded the path value as stated above. Once I did that, it started working. The path name is the same as it was in the debugger with the ifdef in place so I'm not sure why/where this was breaking. If anyone has any further insight it would be fantastic to hear. Hopefully this will help anyone having a similar issue or getting SSL working in QT in general!
Im trying to read from a file and put into to the text edit and it keeps saying QIODevice::read:device not open. The .txt file is in the same location as my .qrc and .cpp file. I was following a step by step guide from online. From my understanding, they changed something when they went from Q4 to Q5. Does anyone have any hint on how I can fix this. thanks
//My findstuff.h
#ifndef FINDSTUFF_H
#define FINDSTUFF_H
#include <QWidget>
namespace Ui {class FindStuff;}
class FindStuff : public QWidget{
Q_OBJECT
public:
explicit FindStuff(QWidget *parent = 0);
~FindStuff();
private slots:
void on_goButton_clicked();
private:
Ui::FindStuff *ui;
void getTextFile();
};
If you're reading from a .qrc resource file you have to run qmake ("Build->Run qmake" in Qt Creator) before it will be available.
You're not passing the absolute path of the file to QFile::open(), and you're not checking the result of opening the file. In your case, it's a failure and open() returns false, but you're ignoring it, instead of fixing the problem (the wrong path) that caused it.
This has zilch to do with Qt 4 -> Qt 5 upgrade, and everything to do with you assuming the wrong thing about the current directory your application happens to find itself with. Generally speaking, the current directory (or working directory) is arbitrary, and platform- and circumstance-specific, and wholly out of your control. Unless the user gives you a filename that's implicitly referenced to the current working directory (e.g. as a relative path given a commandline argument), you must use absolute file paths or things simply won't work.
It can be related to the version of Qt, since Qt5 sometimes doesn't work with MSVC2010.
I have Qt 5.4 and my code gave the same error, when it was working with MSVC2010 OpenGL as a compiler. I manually added MinGW 32bit to use it as compiler and it worked.
P.S. I have not installed MSVC2013 for Qt 5.4., and it works sometimes with MSVC2010 OpenGL without error, but not in this case.
this is mostly the case if you close a file which is not opened - so just remove the close statement for example:
file->close();
just remove it ;)
I had this problem and it turned out Qt Creator hadn't actually added the .qrc file to my project. I'm using Qt Creator 4.1.0 on a Mac and the projects view doesn't always get populated after creating a new project, first requiring a restart of Creator. My version of this problem may relate to that.
It does not have anything to do with Qt version.
Even though your .txt file is in the same directory as your .cpp file, you still need to add the directory. I had the same problem and that simple solution worked well.
Arman Arefi
http://docs.huihoo.com/qt/4.7/demos-declarative-minehunt.html
When I build and run... I just get a blank white rectangle... game is MineHunt.
The source code is in the URL. I created files and copied and pasted into Qt Creator 4.7.
Running in Linux.
No need to downvote. Deploying qml apps does not seem to be easy for beginners. jdl, I don't know if I can help you. Currently I am only on Linux. But what I did:
I copied the whole folder minehunt in my destination folder (/tmp/mine). When I ran qmake I got:
WARNING: Include file
/tmp/mine/helper/qmlapplicationviewer/qmlapplicationviewer.pri not
found
So I also copied the examples/declarative/helper folder into /tmp/mine.
Looked like this:
/tmp
/mine
/minehunt
/helper
Then I changed into minhunt, did 'qmake' and 'make'. A few seconds later I had a working minehunt binary in /tmp/mine/minehunt/.
I'll try tomorrow the Windows build.
Edit: Ok, tried now under Windows 7. Qt4.
QtCreator opened.
Project ...qt\demos\declarative\minehunt\minehunt.pro
loaded. Normally in release mode compiled. No problem. A file minehunt.exe was created in ....qt\demos\declarative\minehunt\release. Started: White screen. Exactly as you described it. In ...qt\demos\declarative\minehunt I found a folder 'qml'. I moved this folder and the minehunt.exe into another folder (myMineFolder). Simulating a simple deployment this way. Clicked on minehunt.exe -> worked like a charm.
So my folder layout:
myMineFolder
qml
minehunt.exe
But of course, I have set my PATH variable correctly to my Qt installation.
Qt creator was working well, but suddenly shows a problem error: LNK1181: cannot open input file 'debug\main.obj'.
This problem shows always with any type of application either GUI or console.
I've uninstall the Qt, and install again, but the problem still exists.
I did not do anything in the Qt creator settings, I left the default settings.
The following application is simple console application occur the same problem in it.
//main.cpp
#include <QCoreApplication>
int main(int argc, char *argv[]){
QCoreApplication a(argc, argv);
return a.exec();
}
Note: I'm using Qt 5.1.1 for Windows 32-bit (VS 2010, OpenGL).
This problem also occurs if the path of your project (name of any folder) contains a white space.
This problem occurs also if you have in the .pro or .pri files something like:
HEADERS += \ \
or
SOURCES += \ \
Okay, we finally have a real answer for this generalized problem instead of the OP's typo problem if that didn't unblock you either.
Actual Problem (black-box perspective): The "Build directory" auto-filled entry breaks for projects inside whitespace directories. Qt Creator actually prohibits you and tells you not to use whitespace when making new Projects. You can still close a new project and re-name it to add whitespace, and Qt Creator will handle it gracefully. If you copy the build directory, even with whitespace in it, and paste that into the field replacing the broken auto-generated path (mine was using relative paths) then JOM will start working correctly, as QMake does not generate any errors. I can't speak for other Make tools.
Make or clone down your project with whitespace
Load it in Qt Creator
Run QMAKE
Select the "Project" button on the left-hand side
Make sure you're in the "Build" tab
Select "Browse", and then re-select the shadow directory QMAKE made
That should unblock you if it wasn't a simple issue for deleting the old QMAKE-generated folders, which is the most common problem people face with this specific error while developing within Qt Creator.
I got the error because of this:
HEADERS += \ \
$$PWD/QOakTreeViewRecursiveModel.h
instead of:
HEADERS += \
$$PWD/QOakTreeViewRecursiveModel.h
What worked for me:
Close the Qt Creator
Delete the [filename].pro.user file in your project directory
Open the project again and let Qt configure itself
Generally whenever I encounter an error like this, this is one of the first things I do as it solves a lot of problems with Qt.
Edit: This will of course reset your project build location.
The problem has been solved.
The cause of the problem was when creating a new project (GUI or Console), all source files that belong to this new project take a wrong extension ex: main.cp, but the correct extension is supposed to be ex: main.cpp.
And when changing all the source files extension from .cp to .cpp worked fine.
Or change the default source file extension from [Tools -> Option -> C++].
hmm If I remember correctly when I faced this kind of problems using your similar setup (QtCreator and Windows) running QMAKE & rebuilding the project again helped me solve this linker errors.
Run Clean and qMake and rebuild.
I has like this problem and this helped me.
I solved the problem by removing the big path and space names in the directories.
Try to create a folder in C:/ and copy or clone the project in this folder.
Remove all builder folders and configure the project again.
That solved it for me.